Make the tap service an APIExtension #2725
Assignees
Labels
Comments
siggy
changed the title
siggy
added a commit
that referenced
this issue
Jul 31, 2019
The Tap Service enabled tapping of any meshed pod, regardless of user privilege. This change introduces a new Tap APIService. Kubernetes provides authentication and authorization of Tap requests, and then forwards requests to a new Tap APIServer, which implements a Kubernetes aggregated API server. The Tap APIServer authenticates the client TLS from Kubernetes, and authorizes the user via a SubjectAccessReview. The `linkerd tap` command now makes requests against the new APIService. The Tap APIService implements three Kubernetes-style endpoints: GET /apis/tap.linkerd.io/v1alpha1 POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/tap POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/:res/:name/tap Users authorize to the new `tap.linkerd.io/v1alpha1` via RBAC. Only the `watch` verb is supported. Access is also available via subresources such as `deployments/tap` and `pods/tap`. This change introduces the following resources into the default Linkerd install: - Global - APIService/v1alpha1.tap.linkerd.io - ClusterRoleBinding/linkerd-linkerd-tap-auth-delegator - `linkerd` namespace: - Secret/linkerd-tap-tls - `kube-system` namespace: - RoleBinding/linkerd-linkerd-tap-auth-reader Tasks not covered by this PR: - `linkerd top` using tap APIService - `linkerd dashboard` using tap APIService - removal of the unauthenticated tap controller Fixes #2725 Signed-off-by: Andrew Seigner <[email protected]>
siggy
added a commit
that referenced
this issue
Jul 31, 2019
The Tap Service enabled tapping of any meshed pod, regardless of user privilege. This change introduces a new Tap APIService. Kubernetes provides authentication and authorization of Tap requests, and then forwards requests to a new Tap APIServer, which implements a Kubernetes aggregated API server. The Tap APIServer authenticates the client TLS from Kubernetes, and authorizes the user via a SubjectAccessReview. The `linkerd tap` command now makes requests against the new APIService. The Tap APIService implements three Kubernetes-style endpoints: GET /apis/tap.linkerd.io/v1alpha1 POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/tap POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/:res/:name/tap Users authorize to the new `tap.linkerd.io/v1alpha1` via RBAC. Only the `watch` verb is supported. Access is also available via subresources such as `deployments/tap` and `pods/tap`. This change introduces the following resources into the default Linkerd install: - Global - APIService/v1alpha1.tap.linkerd.io - ClusterRoleBinding/linkerd-linkerd-tap-auth-delegator - `linkerd` namespace: - Secret/linkerd-tap-tls - `kube-system` namespace: - RoleBinding/linkerd-linkerd-tap-auth-reader Tasks not covered by this PR: - `linkerd top` using tap APIService - `linkerd dashboard` using tap APIService - removal of the unauthenticated tap controller Fixes #2725 Signed-off-by: Andrew Seigner <[email protected]>
siggy
added a commit
that referenced
this issue
Jul 31, 2019
The Tap Service enabled tapping of any meshed pod, regardless of user privilege. This change introduces a new Tap APIService. Kubernetes provides authentication and authorization of Tap requests, and then forwards requests to a new Tap APIServer, which implements a Kubernetes aggregated API server. The Tap APIServer authenticates the client TLS from Kubernetes, and authorizes the user via a SubjectAccessReview. The `linkerd tap` command now makes requests against the new APIService. The Tap APIService implements three Kubernetes-style endpoints: GET /apis/tap.linkerd.io/v1alpha1 POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/tap POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/:res/:name/tap Users authorize to the new `tap.linkerd.io/v1alpha1` via RBAC. Only the `watch` verb is supported. Access is also available via subresources such as `deployments/tap` and `pods/tap`. This change introduces the following resources into the default Linkerd install: - Global - APIService/v1alpha1.tap.linkerd.io - ClusterRoleBinding/linkerd-linkerd-tap-auth-delegator - `linkerd` namespace: - Secret/linkerd-tap-tls - `kube-system` namespace: - RoleBinding/linkerd-linkerd-tap-auth-reader Tasks not covered by this PR: - `linkerd top` using tap APIService - `linkerd dashboard` using tap APIService - removal of the unauthenticated tap controller Fixes #2725 Signed-off-by: Andrew Seigner <[email protected]>
siggy
added a commit
that referenced
this issue
Jul 31, 2019
The Tap Service enabled tapping of any meshed pod, regardless of user privilege. This change introduces a new Tap APIService. Kubernetes provides authentication and authorization of Tap requests, and then forwards requests to a new Tap APIServer, which implements a Kubernetes aggregated API server. The Tap APIServer authenticates the client TLS from Kubernetes, and authorizes the user via a SubjectAccessReview. The `linkerd tap` command now makes requests against the new APIService. The Tap APIService implements three Kubernetes-style endpoints: GET /apis/tap.linkerd.io/v1alpha1 POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/tap POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/:res/:name/tap Users authorize to the new `tap.linkerd.io/v1alpha1` via RBAC. Only the `watch` verb is supported. Access is also available via subresources such as `deployments/tap` and `pods/tap`. This change introduces the following resources into the default Linkerd install: - Global - APIService/v1alpha1.tap.linkerd.io - ClusterRoleBinding/linkerd-linkerd-tap-auth-delegator - `linkerd` namespace: - Secret/linkerd-tap-tls - `kube-system` namespace: - RoleBinding/linkerd-linkerd-tap-auth-reader Tasks not covered by this PR: - `linkerd top` using tap APIService - `linkerd dashboard` using tap APIService - removal of the unauthenticated tap controller Fixes #2725 Signed-off-by: Andrew Seigner <[email protected]>
siggy
added a commit
that referenced
this issue
Jul 31, 2019
The Tap Service enabled tapping of any meshed pod, regardless of user privilege. This change introduces a new Tap APIService. Kubernetes provides authentication and authorization of Tap requests, and then forwards requests to a new Tap APIServer, which implements a Kubernetes aggregated API server. The Tap APIServer authenticates the client TLS from Kubernetes, and authorizes the user via a SubjectAccessReview. The `linkerd tap` command now makes requests against the new APIService. The Tap APIService implements three Kubernetes-style endpoints: GET /apis/tap.linkerd.io/v1alpha1 POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/tap POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/:res/:name/tap Users authorize to the new `tap.linkerd.io/v1alpha1` via RBAC. Only the `watch` verb is supported. Access is also available via subresources such as `deployments/tap` and `pods/tap`. This change introduces the following resources into the default Linkerd install: - Global - APIService/v1alpha1.tap.linkerd.io - ClusterRoleBinding/linkerd-linkerd-tap-auth-delegator - `linkerd` namespace: - Secret/linkerd-tap-tls - `kube-system` namespace: - RoleBinding/linkerd-linkerd-tap-auth-reader Tasks not covered by this PR: - `linkerd top` - `linkerd dashboard` - `linkerd profile --tap` - removal of the unauthenticated tap controller Fixes #2725 Signed-off-by: Andrew Seigner <[email protected]>
siggy
added a commit
that referenced
this issue
Jul 31, 2019
The Tap Service enabled tapping of any meshed pod, regardless of user privilege. This change introduces a new Tap APIService. Kubernetes provides authentication and authorization of Tap requests, and then forwards requests to a new Tap APIServer, which implements a Kubernetes aggregated API server. The Tap APIServer authenticates the client TLS from Kubernetes, and authorizes the user via a SubjectAccessReview. The `linkerd tap` command now makes requests against the new APIService. The Tap APIService implements three Kubernetes-style endpoints: GET /apis/tap.linkerd.io/v1alpha1 (for `kubectl api-resources`) POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/tap POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/:res/:name/tap Users authorize to the new `tap.linkerd.io/v1alpha1` via RBAC. Only the `watch` verb is supported. Access is also available via subresources such as `deployments/tap` and `pods/tap`. This change introduces the following resources into the default Linkerd install: - Global - APIService/v1alpha1.tap.linkerd.io - ClusterRoleBinding/linkerd-linkerd-tap-auth-delegator - `linkerd` namespace: - Secret/linkerd-tap-tls - `kube-system` namespace: - RoleBinding/linkerd-linkerd-tap-auth-reader Tasks not covered by this PR: - `linkerd top` - `linkerd dashboard` - `linkerd profile --tap` - removal of the unauthenticated tap controller Fixes #2725 Signed-off-by: Andrew Seigner <[email protected]>
siggy
added a commit
that referenced
this issue
Jul 31, 2019
The Tap Service enabled tapping of any meshed pod, regardless of user privilege. This change introduces a new Tap APIService. Kubernetes provides authentication and authorization of Tap requests, and then forwards requests to a new Tap APIServer, which implements a Kubernetes aggregated APIServer. The Tap APIServer authenticates the client TLS from Kubernetes, and authorizes the user via a SubjectAccessReview. The `linkerd tap` command now makes requests against the new APIService. The Tap APIService implements three Kubernetes-style endpoints: GET /apis/tap.linkerd.io/v1alpha1 (for `kubectl api-resources`) POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/tap POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/:res/:name/tap Users authorize to the new `tap.linkerd.io/v1alpha1` via RBAC. Only the `watch` verb is supported. Access is also available via subresources such as `deployments/tap` and `pods/tap`. This change introduces the following resources into the default Linkerd install: - Global - APIService/v1alpha1.tap.linkerd.io - ClusterRoleBinding/linkerd-linkerd-tap-auth-delegator - `linkerd` namespace: - Secret/linkerd-tap-tls - `kube-system` namespace: - RoleBinding/linkerd-linkerd-tap-auth-reader Tasks not covered by this PR: - `linkerd top` - `linkerd dashboard` - `linkerd profile --tap` - removal of the unauthenticated tap controller Fixes #2725 Signed-off-by: Andrew Seigner <[email protected]>
siggy
added a commit
that referenced
this issue
Jul 31, 2019
The Tap Service enabled tapping of any meshed pod, regardless of user privilege. This change introduces a new Tap APIService. Kubernetes provides authentication and authorization of Tap requests, and then forwards requests to a new Tap APIServer, which implements a Kubernetes aggregated APIServer. The Tap APIServer authenticates the client TLS from Kubernetes, and authorizes the user via a SubjectAccessReview. This change also modifies the `linkerd tap` command to make requests against the new APIService. The Tap APIService implements three Kubernetes-style endpoints: GET /apis/tap.linkerd.io/v1alpha1 (for `kubectl api-resources`) POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/tap POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/:res/:name/tap Users authorize to the new `tap.linkerd.io/v1alpha1` via RBAC. Only the `watch` verb is supported. Access is also available via subresources such as `deployments/tap` and `pods/tap`. This change introduces the following resources into the default Linkerd install: - Global - APIService/v1alpha1.tap.linkerd.io - ClusterRoleBinding/linkerd-linkerd-tap-auth-delegator - `linkerd` namespace: - Secret/linkerd-tap-tls - `kube-system` namespace: - RoleBinding/linkerd-linkerd-tap-auth-reader Tasks not covered by this PR: - `linkerd top` - `linkerd dashboard` - `linkerd profile --tap` - removal of the unauthenticated tap controller Fixes #2725 Signed-off-by: Andrew Seigner <[email protected]>
siggy
added a commit
that referenced
this issue
Jul 31, 2019
The Tap Service enabled tapping of any meshed pod, regardless of user privilege. This change introduces a new Tap APIService. Kubernetes provides authentication and authorization of Tap requests, and then forwards requests to a new Tap APIServer, which implements a Kubernetes aggregated APIServer. The Tap APIServer authenticates the client TLS from Kubernetes, and authorizes the user via a SubjectAccessReview. This change also modifies the `linkerd tap` command to make requests against the new APIService. The Tap APIService implements three Kubernetes-style endpoints: GET /apis/tap.linkerd.io/v1alpha1 (for `kubectl api-resources`) POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/tap POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/:res/:name/tap Users authorize to the new `tap.linkerd.io/v1alpha1` via RBAC. Only the `watch` verb is supported. Access is also available via subresources such as `deployments/tap` and `pods/tap`. This change introduces the following resources into the default Linkerd install: - Global - APIService/v1alpha1.tap.linkerd.io - ClusterRoleBinding/linkerd-linkerd-tap-auth-delegator - `linkerd` namespace: - Secret/linkerd-tap-tls - `kube-system` namespace: - RoleBinding/linkerd-linkerd-tap-auth-reader Tasks not covered by this PR: - `linkerd top` - `linkerd dashboard` - `linkerd profile --tap` - removal of the unauthenticated tap controller Fixes #2725 Signed-off-by: Andrew Seigner <[email protected]>
siggy
added a commit
that referenced
this issue
Jul 31, 2019
The Tap Service enabled tapping of any meshed pod, regardless of user privilege. This change introduces a new Tap APIService. Kubernetes provides authentication and authorization of Tap requests, and then forwards requests to a new Tap APIServer, which implements a Kubernetes aggregated APIServer. The Tap APIServer authenticates the client TLS from Kubernetes, and authorizes the user via a SubjectAccessReview. This change also modifies the `linkerd tap` command to make requests against the new APIService. The Tap APIService implements three Kubernetes-style endpoints: GET /apis/tap.linkerd.io/v1alpha1 (for `kubectl api-resources`) POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/tap POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/:res/:name/tap Users authorize to the new `tap.linkerd.io/v1alpha1` via RBAC. Only the `watch` verb is supported. Access is also available via subresources such as `deployments/tap` and `pods/tap`. This change introduces the following resources into the default Linkerd install: - Global - APIService/v1alpha1.tap.linkerd.io - ClusterRoleBinding/linkerd-linkerd-tap-auth-delegator - `linkerd` namespace: - Secret/linkerd-tap-tls - `kube-system` namespace: - RoleBinding/linkerd-linkerd-tap-auth-reader Tasks not covered by this PR: - `linkerd top` - `linkerd dashboard` - `linkerd profile --tap` - removal of the unauthenticated tap controller Fixes #2725 Signed-off-by: Andrew Seigner <[email protected]>
siggy
added a commit
that referenced
this issue
Jul 31, 2019
The Tap Service enabled tapping of any meshed pod, regardless of user privilege. This change introduces a new Tap APIService. Kubernetes provides authentication and authorization of Tap requests, and then forwards requests to a new Tap APIServer, which implements a Kubernetes aggregated APIServer. The Tap APIServer authenticates the client TLS from Kubernetes, and authorizes the user via a SubjectAccessReview. This change also modifies the `linkerd tap` command to make requests against the new APIService. The Tap APIService implements three Kubernetes-style endpoints: GET /apis/tap.linkerd.io/v1alpha1 (for `kubectl api-resources`) POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/tap POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/:res/:name/tap Users authorize to the new `tap.linkerd.io/v1alpha1` via RBAC. Only the `watch` verb is supported. Access is also available via subresources such as `deployments/tap` and `pods/tap`. This change introduces the following resources into the default Linkerd install: - Global - APIService/v1alpha1.tap.linkerd.io - ClusterRoleBinding/linkerd-linkerd-tap-auth-delegator - `linkerd` namespace: - Secret/linkerd-tap-tls - `kube-system` namespace: - RoleBinding/linkerd-linkerd-tap-auth-reader Tasks not covered by this PR: - `linkerd top` - `linkerd dashboard` - `linkerd profile --tap` - removal of the unauthenticated tap controller Fixes #2725, #3162 Signed-off-by: Andrew Seigner <[email protected]>
siggy
added a commit
that referenced
this issue
Aug 1, 2019
The Tap Service enabled tapping of any meshed pod, regardless of user privilege. This change introduces a new Tap APIService. Kubernetes provides authentication and authorization of Tap requests, and then forwards requests to a new Tap APIServer, which implements a Kubernetes aggregated APIServer. The Tap APIServer authenticates the client TLS from Kubernetes, and authorizes the user via a SubjectAccessReview. This change also modifies the `linkerd tap` command to make requests against the new APIService. The Tap APIService implements three Kubernetes-style endpoints: GET /apis/tap.linkerd.io/v1alpha1 (for `kubectl api-resources`) POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/tap POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/:res/:name/tap Users authorize to the new `tap.linkerd.io/v1alpha1` via RBAC. Only the `watch` verb is supported. Access is also available via subresources such as `deployments/tap` and `pods/tap`. This change introduces the following resources into the default Linkerd install: - Global - APIService/v1alpha1.tap.linkerd.io - ClusterRoleBinding/linkerd-linkerd-tap-auth-delegator - `linkerd` namespace: - Secret/linkerd-tap-tls - `kube-system` namespace: - RoleBinding/linkerd-linkerd-tap-auth-reader Tasks not covered by this PR: - `linkerd top` - `linkerd dashboard` - `linkerd profile --tap` - removal of the unauthenticated tap controller Fixes #2725, #3162 Signed-off-by: Andrew Seigner <[email protected]>
siggy
added a commit
that referenced
this issue
Aug 1, 2019
The Tap Service enabled tapping of any meshed pod, regardless of user privilege. This change introduces a new Tap APIService. Kubernetes provides authentication and authorization of Tap requests, and then forwards requests to a new Tap APIServer, which implements a Kubernetes aggregated APIServer. The Tap APIServer authenticates the client TLS from Kubernetes, and authorizes the user via a SubjectAccessReview. This change also modifies the `linkerd tap` command to make requests against the new APIService. The Tap APIService implements three Kubernetes-style endpoints: GET /apis/tap.linkerd.io/v1alpha1 (for `kubectl api-resources`) POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/tap POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/:res/:name/tap Users authorize to the new `tap.linkerd.io/v1alpha1` via RBAC. Only the `watch` verb is supported. Access is also available via subresources such as `deployments/tap` and `pods/tap`. This change introduces the following resources into the default Linkerd install: - Global - APIService/v1alpha1.tap.linkerd.io - ClusterRoleBinding/linkerd-linkerd-tap-auth-delegator - `linkerd` namespace: - Secret/linkerd-tap-tls - `kube-system` namespace: - RoleBinding/linkerd-linkerd-tap-auth-reader Tasks not covered by this PR: - `linkerd top` - `linkerd dashboard` - `linkerd profile --tap` - removal of the unauthenticated tap controller Fixes #2725, #3162 Signed-off-by: Andrew Seigner <[email protected]>
siggy
added a commit
that referenced
this issue
Aug 1, 2019
The Tap Service enabled tapping of any meshed pod, regardless of user privilege. This change introduces a new Tap APIService. Kubernetes provides authentication and authorization of Tap requests, and then forwards requests to a new Tap APIServer, which implements a Kubernetes aggregated APIServer. The Tap APIServer authenticates the client TLS from Kubernetes, and authorizes the user via a SubjectAccessReview. This change also modifies the `linkerd tap` command to make requests against the new APIService. The Tap APIService implements these Kubernetes-style endpoints: POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/tap POST /apis/tap.linkerd.io/v1alpha1/watch/namespaces/:ns/:res/:name/tap GET /apis GET /apis/tap.linkerd.io GET /apis/tap.linkerd.io/v1alpha1 GET /healthz GET /healthz/log GET /healthz/ping GET /metrics GET /openapi/v2 GET /version Users authorize to the new `tap.linkerd.io/v1alpha1` via RBAC. Only the `watch` verb is supported. Access is also available via subresources such as `deployments/tap` and `pods/tap`. This change introduces the following resources into the default Linkerd install: - Global - APIService/v1alpha1.tap.linkerd.io - ClusterRoleBinding/linkerd-linkerd-tap-auth-delegator - `linkerd` namespace: - Secret/linkerd-tap-tls - `kube-system` namespace: - RoleBinding/linkerd-linkerd-tap-auth-reader Tasks not covered by this PR: - `linkerd top` - `linkerd dashboard` - `linkerd profile --tap` - removal of the unauthenticated tap controller Fixes #2725, #3162, #3172 Signed-off-by: Andrew Seigner <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Depends on #2712
The tap service should be registered as an APIExtension so that it can ensure that all traffic that it receives has been authenticated and authorized by the API aggregation layer. This allows to use RBAC to control which users and service accounts may access tap data.
On startup, the tap service should generate a serving CA, private key, and certificate and give the CA when registering as an APIExtension by posting to the ApiregistrationV1 API. (Note that generating this material on startup means that the tap service may not run multiple replicas (HA mode). As part of #2176, this can be resolved by generating this material at install time and saving the CA key in a secret.)
The tap server should read the
extension-apiserver-authenticationconfigmap to get the client CA to use to validate the identity of calling clients. This should be used to only allow tap requests from the aggregator. This ensures all requests have been authorized.By serving the tap TAP on
POST /apis/tap.linkerd.io/v1alpha1/namespaces/<ns>/tapswe cause the aggregator to check that the authenticated user has "create" permission on the "taps" resource in the "<ns>" namespace.The text was updated successfully, but these errors were encountered: