kumahq / kuma Goto Github PK

There should be an option to apply multiple resources

name: backend-01
mesh: default
type: Dataplane
networking:
  inbound:
    - interface: 127.0.0.1:8080:8090
      tags:
        service: backend
        version: "1.0"
        env: production
  outbound:
    - interface: :30000
      service: postgres
      servicePort: 5432

---
name: backend-02
mesh: default
type: Dataplane
networking:
  inbound:
    - interface: 127.0.0.1:8080:8090
      tags:
        service: backend
        version: "1.0"
        env: production
  outbound:
    - interface: :30000
      service: postgres
      servicePort: 5432

Resources can have different types.

The API server should always listen on https, and we should provide the following functionality:

• Auto-generate self-signed certificates for the API.
• Allow the user to specify his own certificates.

When i'm trying to run more than one service, i'm getting the error:

unable to bind domain socket with id=0 (see --base-id option)
Error: exit status 1

I think this is related to Envoy proxy!!!

Create deb/rpm packages and Docker images for:

• ubuntu:18.04
• ubuntu:16.04
• ubuntu:14.04
• debian:9
• debian:8
• rhel:7
• centos:7
• amazonlinux:2
• alpine:3.9

To determine if mTLS is enabled or not.

For example:

$ kumactl apply -f http://somewhere

This mode is crucial for rapid prototyping and minimizing time-to-market (if Konvoy Server (side car) is only observing traffic, users will be more comfortable with going to production asap)

I like @yskopets idea:

$ konvoyctl config control-planes add --auto-discover

Searching for Control Planes ...

> Searching for Control Planes installed on Kuberenetes
>> Checking `kubectl` context ...
>>> Searching for Control Plane inside `minikube` context ...
+++ Found Control Plane inside `minikube` context

The following Control Planes have been found on Kubernetes:
CONTEXT NAMESPACE 
minikube   konvoy-system
gke-test      konvoy-system
gke-pro      konvoy-system

For example:

$ kumactl get dataplanes
MESH      NAME        TAGS           STATUS   LAST CONNECTED AGO   LAST UPDATED AGO   TOTAL UPDATES   TOTAL ERRORS
default   dp-echo-1   service=echo   Online   4m47s                4m46s              2               0

and for the simplified version:

$ kumactl get dataplanes --compact
MESH      NAME        TAGS
default   dp-echo-1   service=echo

Summary

Standard installation fails due to missing docker image.

Steps To Reproduce

1. Download kuma-0.1.0-darwin.tar.gz
2. run ./bin/kumactl install control-plane | kubectl apply -f -
3. kubectl -n kuma-system describe pods | grep Failed
   Warning Failed 11m (x4 over 12m) kubelet, kind-control-plane Failed to pull image "kong-docker-kuma-docker.bintray.io/kuma-injector:0.1.0-2-ga5a27f5": rpc error: code = Unknown desc = failed to resolve image "kong-docker-kuma-docker.bintray.io/kuma-injector:0.1.0-2-ga5a27f5": no available registry endpoint: kong-docker-kuma-docker.bintray.io/kuma-injector:0.1.0-2-ga5a27f5 not found

Additional Details & Logs

This commit appears to be responsible for the error.
https://github.com/Kong/kuma/commit/d047661f7e5213f641332918ec190c75d8b4976d

• Version 0.1.0-2-ga5a27f5

• Error logs
  $ docker pull kong-docker-kuma-docker.bintray.io/kuma-injector:0.1.0-2-ga5a27f5
  Error response from daemon: manifest for kong-docker-kuma-docker.bintray.io/kuma-injector:0.1.0-2-ga5a27f5 not found: manifest unknown: The named manifest is not known to the registry.

• Configuration

• Platform and Operating System
  mac os running kubernetes in kind

When running kuma control plane with postgres, i get this error:

kuma-cp.run	problem running Control Plane	{"error": "failed to execute query: SELECT spec, version FROM resources WHERE name=$1 AND namespace=$2 AND mesh=$3 AND type=$4;: pq: relation \"resources\" does not exist", "errorVerbose": "pq: relation \"resources\" does not exist\nfailed to execute query: SELECT spec, version FROM resources WHERE name=$1 AND namespace=$2 AND mesh=$3 AND type=$4;\ngithub.com/Kong/kuma/pkg/plugins/resources/postgres.(*postgresResourceStore).Get\n\t/home/ec2-user/kuma/pkg/plugins/resources/postgres/store.go:143\ngithub.com/Kong/kuma/pkg/core/managers/apis/mesh.(*meshManager).Get\n\t/home/ec2-user/kuma/pkg/core/managers/apis/mesh/mesh_manager.go:34\ngithub.com/Kong/kuma/pkg/core/resources/manager.(*customizableResourceManager).Get\n\t/home/ec2-user/kuma/pkg/core/resources/manager/customizable_manager.go:23\ngithub.com/Kong/kuma/pkg/core/bootstrap.createDefaultMesh\n\t/home/ec2-user/kuma/pkg/core/bootstrap/bootstrap.go:70\ngithub.com/Kong/kuma/pkg/core/bootstrap.onStartup.func1\n\t/home/ec2-user/kuma/pkg/core/bootstrap/bootstrap.go:101\ngithub.com/Kong/kuma/pkg/core/runtime.ComponentFunc.Start\n\t/home/ec2-user/kuma/pkg/core/runtime/component.go:15\ngithub.com/Kong/kuma/pkg/plugins/bootstrap/universal.(*componentManager).Start.func1\n\t/home/ec2-user/kuma/pkg/plugins/bootstrap/universal/component_manager.go:26\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1337"}
Error: failed to execute query: SELECT spec, version FROM resources WHERE name=$1 AND namespace=$2 AND mesh=$3 AND type=$4;: pq: relation "resources" does not exist

• Making sure that the tags have the mandatory service field.
• Making sure that inboud is always present.
• Validate the values in each field, including making sure that the interface value matches the right format.
• Making sure the names are valid with no weird characters (ie, [a-zA-Z0-9\-\_]+).
• And so on.

But really, do this for every object not just Dataplane.

Not just in TrafficPermission, but in every policy.

For example:

$ kumactl describe dp-echo-1 --mesh default
type: Dataplane
mesh: default
name: backend-1
networking:
  inbound:
  - interface: 127.0.0.1:8000:80
    tags:
      service: backend
  outbound:
  - interface: :10000
    service: redis

type: Mesh
name: default
mesh: default
mtls:
  enabled: true
  ca:
    builtin: {}

becomes:

type: Mesh
name: default
mtls:
  enabled: true
  ca:
    builtin: {}

We need to describe a process of releasing new version of Kuma.
It should update the kumactl version, kuma-dp version and / on api-server etc.

It should display:

{
	"tagline": "Kuma",
	"version": "0.1.0"
}

and perhaps even display the loaded configuration for debugging purposes.

When adding a new control-plane to kumactl, verify that effectively the API server is reachable and most importantly that it is a valid Kuma API server.

Would be awesome if kuma could implement SMI (Service Mesh Interface) for easier interoperability

https://github.com/deislabs/smi-spec

Summary

Update to go 1.12.9 or go 1.13 in order to address https://nvd.nist.gov/vuln/detail/CVE-2019-14809

When starting to use kumactl in a new environment, automatically create the local control-plane configuration in kumactl.

When kumactl tries to apply on a Kuma cluster that runs on Kubernetes, block the operation with a user-friendly message.

Summary

Support for ARM64 would be grand.

There should be kumactl install postgres-schema command that prints the postgres schema to apply.

At the moment, we have to buffer a complete response from a Konvoy gRPC server before allowing Envoy to continue iteration over the next filter in the chain.

It seems that the simplest and most intuitive way to configure Konvoy Server (side car) is by passing through configuration of Konvoy Filter

As per title.

Currently, if the user provides invalid input to konvoyctl apply, the error message isn't very helpful:

./build/artifacts/konvoyctl/konvoyctl apply -f examples/resources/mesh.yaml  
Error: unexpected status code: 400

In this case, the mesh field was missing from the input.

When kuma-dp starts it should validate that effectively there is a service running at the location specified by the inbound object in the Dataplane configuration.

It should be possible to pass through Konvoy binary connections (L4)

Instead of 200 OK:

$ curl -i -X DELETE http://localhost:5681/meshes/asd
HTTP/1.1 200 OK
Date: Sun, 08 Sep 2019 19:28:16 GMT
Content-Length: 0

Summary

Right now permissions matches on every outbound interface of the dataplane. They should match on proper service.

Provide a sample service for demo purposes that can echo back the requests we are making, it could be using something like https://echo.labstack.com/guide under the hood.

The executable will be called echo-http-example. Ideally, we could also build a gRPC variant of it (echo-grpc-example).

And prevent data-planes from executing requests. Useful for development.

Hi guys,

I’d like to get your feedback on a solution for konvoyctl list dataplanes I’ve been working on.

The root concern for me is compliance with our platform-agnosticity requirements.

What seems a natural approach to me might be perceived as non platform-agnostic by you.

So, I’ll better ask.

—

As part of konvoyctl list dataplanes use case, konvoyctl tool needs to fetch data about dataplanes.

There are a few options where to fetch those data from:

1: konvoyctl fetches data from environment-native API

• k8s path: konvoyctl => kube-apiserver (k8s CRDs)
• non-k8s path: konvoyctl => konvoy API => Postgres

2: konvoyctl fetches data from Konvoy API only (and doesn’t know about k8s CRDs)

• k8s path: konvoyctl => konvoy API => kube-apiserver (k8s CRDs)
• non-k8s path: konvoyctl => konvoy API => Postgres

Option 1:

• Pros
  • Technically simpler solution
  • Embraces k8s RBAC model (a user can only see those dataplanes that he has permissions on)
• Cons
  • konvoyctl must be aware of 2 different sources of data (k8s CRDs and Konvoy API)
  • Although interacting with kube-apiserver (CRDs) might be enough in this use case, in the future we might still need to make requests directly to konvoy API

Option 2:

• Pros
  • konvoyctl has only 1 source of data (Konvoy API)
• Cons
  • Konvoy API must return k8s specific information (e.g., Namespace)
  • k8s RBAC model is ignored by default (see notes below on how kubectl proxy can help)
• Notes
  • Although konvoyctl might seem platform-agnostic at this point, it’s not a complete picture
  • konvoyctl must be able to connect to konvoy API deployed inside k8s
    • it is not acceptable to force users to expose konvoy API outside of the cluster
    • as a result, konvoyctl must use k8s api to connect directly to konvoy API. There 2 options
      • kubectl port-forward (analog of its behaviour)
      • kubectl proxy (analog of its behaviour)
    • kubectl port-forward establishes a direct TCP connection into a Pod where konvoy API is deployed
      • Kubernetes will check if a user has permission to do kubectl port-forward on a target Pod
      • However, after that security context is lost (we cannot restrict further what a user can or cannot request from konvoy API)
      • Which means that konvoyctl list dataplabes can be used by sys admins, but unlikely by regular users (app developers)
    • kubectl proxy is an HTTP proxy integrated into kube-apiserver
      • Instead of making an HTTP request directly into konvoy API, it could be made via kube-apiserver
        • Kubernetes will check if a user has permissions to do kubectl proxy on a Service of konvoy API
        • Kubernetes will proxy the HTTP request and forward it to konvoy API, including information about the user (name, groups)
        • konvoy API can use forwarded info about a user to enforce RBAC (by making a reverse call into k8s APIs)
        • konvoy API should support a version of API that includes Namespaces, e.g. all 3 options below
          • /dataplanes (to serve requests equivalent to kubectl get dataplanes --all-namespaces)
          • /meshes/:name/dataplanes (to serve requests equivalent to kubectl get dataplanes --field-selector=“.mesh=pilot” --all-namespaces)
          • /meshes/:name/namespaces/:ns/dataplanes (to serve requests equivalent to kubectl get dataplanes --field-selector=“.mesh=pilot” -n my-namespace)

Option 2 has a longer description, but it shouldn’t discourage you

• I double checked, both Istio and Linkerd use kubectl port-forward in some use cases

Please let me know which option you prefer

In every executable.

There should be support for passing k8s namespace when retrieving a single object from API server. Otherwise we won't be able to retrieve a single object using Konvoy API on K8S deployments.

Add templates for GitHub issues and pull requests.

Summary

SUMMARY_GOES_HERE

Support for third-party CA authority to sign our mTLS certificates as opposed to the self-signed ones.

Summary

Clang-format is a dependency that is not stated or included in the Makefile.

Steps To Reproduce

1. Follow DEVELOPER.MD steps and install dev tools with make dev/tools
2. make build
3. make run/universal/memory
   outputs:

go fmt ./...
make fmt -C pkg/plugins/resources/k8s/native
go fmt ./...
find . -name '*.proto' | xargs -L 1 clang-format -i
xargs: clang-format: No such file or directory
make: *** [fmt/proto] Error 127 

since clang-format is not installed. The documentation also does not recognize it as a dependency. Need to implement the following:

1. Makefile installs clang-format if does not exist
   and
2. Update DEVELOPER.md to state that clang-format is a dependency

kuma-dp has a dependency on envoy and it will try to invoke envoy from the $PATH. As a fallback, it would be great if kuma-dp could also look for envoy in the same folder from where kuma-dp was launched.

Reported by @john-paul-keenan

How to remove a control-plane added via kumactl ?

Summary

Support DTLS or UDP routing? This is useful for game server hosting that uses kuma as a load balancer and for things like internet of things endpoints.

Steps To Reproduce

Use kuma.

Additional Details & Logs

• Version 2291f05

Summary

SUMMARY_GOES_HERE

Steps To Reproduce

Additional Details & Logs

• Version
• Error logs
• Configuration
• Platform and Operating System

can offer the functions kuma mange kubernets application,and give some examples

For the service mTLS certificates.