Kubernetes Impersonation with an outside proxy

I’m getting close to get the Kubernetes integration working (I can kubectl get nodes from my machine), but now I’m trying to understand and apply the Kubernetes Impersonation.

First question, when in the doc you say “Teleport is running inside the cluster”, does it mean as a Kubernetes pod, or does it mean on a Kubernetes cluster node?

Reading the doc, it looks clear for all the other cases than “If Teleport is running outside of the Kubernetes cluster”, but for this case, there a very short line and you’re done. So I’m honestly lost on what shall I do here.

I’m assuming “running outside of the Kubernetes cluster” means not as a pod within Kubernetes, and as I’ve deployed the Teleport proxy on a node of my k8s cluster, I consider being in the outside case.

So here is the documentation for my case :

If Teleport is running outside of the Kubernetes cluster, you will need to ensure that the principal used to connect to Kubernetes via the kubeconfig file has the same impersonation permissions as are described in the ClusterRole above.

Question 1 : Is there a missing word in “the principal used to connect”? I don’t really get if it’s the principal account/cluster/… ?
Question 2 : I guess I should use the same file as the Helm chart to create the service account and then re-use the same name in the ClusterRole?
Question 3 : How can I check my config is working fine?

I think the main point of my topic is that the Kubernetes documentation needs some more love :slight_smile:.
(There are some “old” links like in the Kubernetes Integration from the Admin guide which says take a look at Kubernetes Integration with SSH section in the Architecture chapter, which seems to be actually the current chapter as this chapter doesn’t exist in the Architecture chapter.)

Thank you in advance.

It means when Teleport is running inside a k8s pod. This is because all pods will automatically get the correct config for API server access mounted inside the pod under /run/secrets/kubernetes.io/serviceaccount

If the credentials are not available at /run/secrets/kubernetes.io/serviceaccount, you will need to provide a kubeconfig file (as can be generated by running https://github.com/gravitational/teleport/blob/master/examples/gke-auth/get-kubeconfig.sh)

Correct.

Given this example kubeconfig:

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: <redacted>
    server: <server address>
  name: k8s
contexts:
- context:
    cluster: k8s
    user: teleport
  name: k8s
current-context: k8s
kind: Config
preferences: {}
users:
- name: teleport
  user:
    client-certificate-data: <redacted>
    client-key-data: <redacted>

The principal in this example is teleport - i.e. the user which is actually connecting to the cluster.

From Teleport for EKS Dev Build Guide - here is an example ServiceAccount, ClusterRole and ClusterRoleBinding:

apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    app: teleport
  name: teleport
  namespace: default
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app: teleport
  name: teleport
rules:
- apiGroups:
  - ""
  resources:
  - users
  - groups
  - serviceaccounts
  verbs:
  - impersonate
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    app: teleport
  name: teleport
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: teleport
subjects:
- kind: ServiceAccount
  name: teleport
  namespace: default

Apply these configurations to your k8s cluster, log into your Teleport cluster, then check that the kubectl context is set correctly (with kubectl config get-contexts). If it’s pointing at your Teleport Kubernetes proxy, run something like kubectl --v=7 get pods and you’ll see where the requests are headed. This will be to the Kubernetes port on your Teleport proxy server - 3026 by default. If you get a pod listing back, it’s working.

You can also check your Kubernetes API server logs to see the incoming requests, although you may need to alter the audit policy to capture details of such events. You will need to do this for sure if you get 403 Forbidden or similar coming back from your kubectl command.

I agree that the documentation could probably be clearer. There’s an open issue already (https://github.com/gravitational/teleport/issues/2746) to generally improve the k8s documentation and provide some more relevant examples.

1 Like

This topic was automatically closed 12 hours after the last reply. New replies are no longer allowed.