While using Kubernetes clusters of different distributions like – AKS, GKE, EKS, OpenShift, and ICP we need to give specific privileges to a specific user/user group. During this process, to give restricted access to a cluster we can make use of a service account.
Before we begin, it is assumed that you have already created a Kubernetes cluster and have configured kubectl to connect to it. Moreover, this blog post describes how service accounts can be set up and their behavior in a cluster which is recommended in a Kubernetes project.
Follow the below procedure to quickly setup up Kubernetes API Access using a Service Account:
- Use kubectl to create a service account. For example:
$ kubectl create serviceaccount test-user
- Bind the service account to the appropriate roles to grant privileges. For example:
$ kubectl create clusterrolebinding test-user-binding --clusterrole=cluster-admin --serviceaccount=default:test-user
- You now have a service account bound to the appropriate roles. To use this account, you need to get the token in its secret.
- Retrieve the token associated with the account.
- The token is stored in the secret of the service account.
- First, locate the secret associated with the account.
$ kubectl get secrets
- This command returns a list of secrets that looks something like this.
NAME TYPE DATA AGE default-token-2kf6w kubernetes.io/service-account-token 3 30d k8s-nginx-ingress-token-h79rc kubernetes.io/service-account-token 3 21h test-user-token-l8mrf kubernetes.io/service-account-token 3 12m
- Then use the kubectl describe command see the token in the secret. For example:
$ kubectl describe secret test-user-token-l8mrf
- This command returns a description of the secret, which contains the token. For example:
Name: test-user-token-l8mrf Namespace: default Labels: <none> Annotations: kubernetes.io/service-account.name=test-user kubernetes.io/service-account.uid=aa1c318a-bc3d-11e8-b171-023b9d05d78 Type: kubernetes.io/service-account-token Data ==== ca.crt: 33605 bytes namespace: 7 bytes token: eyJhb3ciOi . . . [output snipped]
- You can optionally put the token into an environment variable which provides a convenient way to access it.
- Use the following command, replacing my-build-worker-account-token-rq3ls with the name of the secret.
$ export TOKEN=$(kubectl get secret test-user-token-l8mrf -o=jsonpath="{.data.token}" | base64 -D -i -)
Note:
- This is a MacOS command. You might have to adjust appropriately for your operating system.
- Test the token.
- Use cURL to access an API in your cluster, pulling the token from the environment variable you created. In the following command, replace cluster-address with the address of your Smart Cluster.
$ curl -H "Authorization: Bearer $TOKEN" https://api.cluster-address/api/v1/pods -k
- This command returns a list of the pods in your Smart Cluster in JSON format.
"kind": "PodList", "apiVersion": "v1", "metadata": { "selfLink": "/api/v1/pods", "resourceVersion": "4781803" }, "items": [ { ... [output snipped]
Results:
- Now you have a service account with a long-lived token that you can use to authenticate to Kubernetes.
- Below is the existing Kubeconfig on machine.
apiVersion: v1 clusters: cluster: certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZ….[snipped] server: https://xx.xxx.xx.xxx name: gke_cluster-138506_us-east1-b_gc-test1 contexts: context: cluster: gke_cluster-138506_us-east1-b_gc-test1 user: gke_cluster-138506_us-east1-b_gc-test1 name: gke_cluster-138506_us-east1-b_gc-test1 current-context: gke_cluster-138506_us-east1-b_gc-test1 kind: Config preferences: {} users: name: gke_cluster-138506_us-east1-b_gc-test1 user: auth-provider: config: access-token: ya29.c.El_YBjiORx69G_PzzJ...[snippet] cmd-args: config config-helper --format=json cmd-path: path expiry: "2019-03-26T06:42:04Z" expiry-key: '{.credential.token_expiry}' token-key: '{.credential.access_token}' name: gcp
- Replace user and its token at highlighted places:
apiVersion: v1 clusters: - cluster: certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0F….[snipped] server: https://xxx.xxx.xx.XXX name: gke_cluster-138506_us-east1-b_gc-test1 contexts: context: cluster: gke_cluster-138506_us-east1-b_gc-test1 user: test-user name: gke_cluster-138506_us-east1-b_gc-test1 current-context: gke_cluster-138506_us-east1-b_gc-test1 kind: Config preferences: {} users: name: test-user user: token: eyJhb3ciOi . . . [output snipped]
And that’s a wrap! CloudHedge uses BYOC (Bring Your Own Cluster) feature to import any Kubernetes Cluster during the migration and deployment of mission-critical apps from legacy to cloud. In my next blog post, I would be covering how to bring and deploy your own cluster using Cruize, a CloudHedge product. Contact us – hello@cloudhedge.io to migrate your age-old legacy applications to cloud.