kubectl impersonation does not work through teleport

[drewwells]

Description

What happened: Trying to impersonate users with the kubectl auth can-i call.

kubectl auth --as=user --as-group=system:masters can-i get pod -v8 2>&1 | egrep imperson                                                            
I0115 16:21:35.201906 1429251 request.go:1017] Response Body: {"message":"impersonation request has been denied, user header \"user\" is not allowed in roles"}
I0115 16:21:35.201996 1429251 request.go:1220] body was not decodable (unable to check for Status): Object 'Kind' is missing in '{"message":"impersonation request has been denied, user header \"user\" is not allowed in roles"}'

What you expected to happen: I expected to query k8s rbac to see if system:master can access pods in the cluster.

kubectl auth can-i get pod --as=user --as-group=system:masters                                                                                                                         
yes

How to reproduce it (as minimally and precisely as possible): Attempt any kubectl call with --as={user} and/or --as-group={group} that doesn't match exactly what is given in the teleport impersonation.

Environment

• Teleport version (use teleport version): server 4.4.6 client 4.2.0

• Tsh version (use tsh version): N/A

• OS (e.g. from /etc/os-release): N/A

• Where are you running Teleport? (e.g. AWS, GCP, Dedicated Hardware): dedicated hardware Browser environment N/A

• Browser Version (for UI-related issues):

• Install tools:

• Others:

Relevant Debug Logs If Applicable

• tsh --debug
• teleport --debug

[awly]

I don't know if we can do much about this. Impersonation is the mechanism that Teleport uses under the hood to pass user identity to the Kubernetes API. We'd need to somehow evaluate whether users/groups in your Teleport roles can impersonate the users/groups passed via kubectl --as.... Which also opens up new vulnerability surface.

I do agree that using impersonation on the client is useful for debugging.

[drewwells]

I figured it was a tough feature request. It appears that the SubjectAccressReview is happening prior to impersonation, or rather teleport is trying to interpret it. If we impersonated the user, then forwarded the kubectl call along to apiserver. It would perform the correct authorization in reviewing the call.

[dmitry-mightydevops]

Yes I got the same issue: https://github.com/kubernetes/kubernetes/issues/104637

[tamcore]

Are there any news on this? Even creating a generous role with

spec:
  allow:
    impersonate:
      roles:
      - '*'
      users:
      - '*'
    kubernetes_groups:
    - '*'
    kubernetes_users:
    - '*'

does not seem to help.

$ kubectl auth can-i get pods --as=foo
Error from server: impersonation request has been denied, user header "foo" is not allowed in roles

2022-07-07T10:27:49Z ERRO [PROXY:PRO] Failed to set up forwarding headers: impersonation request has been denied, user header "foo" is not allowed in roles. proxy/forwarder.go:1428

And if the user already has all possible wildcards, security shouldn't be a concern.

[tigrato]

@tamcore, wildcard * is not supported for kubernetes_groups and kubernetes_users .

You must specify the allowed groups and users before using --as foo. In order for the request to be successful, foo must be allowed in kubernetes_users.

[tigrato]

This feature is already supported except for the wildcard. A user can select a subset of kubernetes_groups and/or kubernetes_users when using --as-groups and/or --as kubectl flags