ServiceAccount

Authentication and ServiceAccounts

Kubernetes users are classified into service accounts (ServiceAccounts) and common accounts.

• A ServiceAccount is bound to a namespace and associated with a set of credentials stored in a secret. When a pod is created, the secret is mounted to the pod so that the pod can be called by the API Server.
• Kubernetes does not have objects that represent common accounts. By default, these accounts are managed by external services. For example, CCE users on HUAWEI CLOUD are managed by Identity and Access Management (IAM).

The following only focuses on ServiceAccounts.

Similar to pods and ConfigMaps, ServiceAccounts are resources in Kubernetes and apply to independent namespaces. That is, a ServiceAccount named default is automatically created when a namespace is created.

Run the following command to view ServiceAccounts:

$ kubectl get sa
NAME     SECRETS   AGE
default  1         30d

In addition, Kubernetes automatically creates a secret for a ServiceAccount. Run the following command to view the secret:

$ kubectl describe sa default
Name:                default
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   default-token-vssmw
Tokens:              default-token-vssmw
Events:              <none>

In the pod definition file, you can assign a ServiceAccount to a pod by specifying an account name. If no account name is specified, the default ServiceAccount is used. When receiving a request with an authentication token, the API Server uses the token to check whether the ServiceAccount associated with the client that sends the request allows the request to be executed.

Creating a ServiceAccount

Run the following command to create a ServiceAccount:

$ kubectl create serviceaccount sa-example
serviceaccount/sa-example created

$ kubectl get sa
NAME            SECRETS   AGE
default         1         30d
sa-example      1         2s

The token associated with the ServiceAccount has been created.

$ kubectl describe sa sa-example
Name:                sa-example
Namespace:           default
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   sa-example-token-c7bqx
Tokens:              sa-example-token-c7bqx
Events:              <none>

Check the secret content. You can find the ca.crt, namespace, and token data.

$ kubectl describe secret sa-example-token-c7bqx
Name:         sa-example-token-c7bqx
...
Data
====
ca.crt:     1082 bytes
namespace:  7 bytes
token:      <token content>

Using a ServiceAccount in a Pod

It is convenient to use a ServiceAccount in a pod. You only need to specify the name of the ServiceAccount.

apiVersion: v1
kind: Pod
metadata:
  name: sa-example
spec:  
  serviceAccountName: sa-example
  containers:
  - image: nginx:alpine             
    name: container-0               
    resources:                      
      limits:
        cpu: 100m
        memory: 200Mi
      requests:
        cpu: 100m
        memory: 200Mi
  imagePullSecrets:            
  - name: default-secret

Create a pod and view its information. You can see that sa-example-token-c7bqx is mounted to the pod, that is, the token corresponding to the ServiceAccount sa-example. That is, the pod uses the token for authentication.

$ kubectl create -f sa-pod.yaml
pod/sa-example created

$ kubectl get pod
NAME                                       READY   STATUS              RESTARTS   AGE
sa-example                                 0/1     running             0          5s

$ kubectl describe pod sa-example
...
Containers:
  sa-example:
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from sa-example-token-c7bqx (ro)

You can also view the corresponding file in the pod.

$ kubectl exec -it sa-example -- /bin/sh
/ # cd /run/secrets/kubernetes.io/serviceaccount
/run/secrets/kubernetes.io/serviceaccount # ls
ca.crt     namespace  token

As shown above, in a containerized application, ca.crt and token can be used to access the API Server.

Then check whether the authentication takes effect. In a Kubernetes cluster, a Service named kubernetes is created for the API Server by default. The API Server can be accessed through this service.

$ kubectl get svc
NAME           TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
kubernetes     ClusterIP   10.247.0.1       <none>        443/TCP          34

Go to the pod and run the curl command. If the following information is displayed, you do not have the permission.

$ kubectl exec -it sa-example -- /bin/sh
/ # curl https://kubernetes
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Use ca.crt and token for authentication. The specific procedure is as follows: Place ca.crt in the environment variable CURL_CA_BUNDLE, and run the curl command to specify the certificate using CURL_CA_BUNDLE. Place the token content in TOKEN and use the token to access the API Server.

# export CURL_CA_BUNDLE=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
# TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
# curl -H "Authorization: Bearer $TOKEN" https://kubernetes
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {

  },
  "status": "Failure",
  "message": "forbidden: User \"system:serviceaccount:default:sa-example\" cannot get path \"/\"",
  "reason": "Forbidden",
  "details": {

  },
  "code": 403
}