21. Kubernetes (k8s) note authentication, authorization and access control (I) authentication serviceaccount

Time:2022-5-6

summary:

1. Kubernetes API access control

Official documents:
https://kubernetes.io/zh/docs…
Kubernetes API is divided into authentication, authorization and admission control

  • Users access the API through kubectl, client libraries, or by sending rest requests. Both users (natural persons) and kubernetes service accounts can be authorized to access the API. After the request reaches the API server, it will go through several stages, as shown in the figure:
    21. Kubernetes (k8s) note authentication, authorization and access control (I) authentication serviceaccount
  • First, let’s take a look at the initiation of kubernetes API request. The initiation of request is divided into two parts:
  • The first part is the process of human-computer interaction. It is a very familiar request process for apiserver with kubectl, which uses the users accounts general account;
  • The second part is the interaction between the business logic in pod and apiserver, using the service accounts service account.
  • When our apiserver receives the request, it will start the access control process. There are three steps:
  1. Authentication phase: judge whether the requesting user is a legal user who can access the cluster. If the user is an illegal user, apiserver will return a 401 status code and terminate the request;
  2. If the user is legal, our apiserver will enter the second stage of access control: authorization. In this stage, apiserver will judge whether the user has permission to perform the operation in the request. If you are not authorized to operate, apiserver will return the status code of 403 and terminate the request;
  3. If the user has the right to perform this operation, access control will enter the third stage: admissioncontrol. In this stage, apiserver’s admission controller will judge whether the request is a security compliant request. If the final verification is passed, the access control process will end.

At this point, our request will be converted into a corresponding change request for kubernetes objects, and finally persisted to etcd.

Authentication (any kind) – > authorization (generally RBAC and node) – > admission control (choose by yourself)
21. Kubernetes (k8s) note authentication, authorization and access control (I) authentication serviceaccount

2. Authentication

There are many kinds of authentication. You can start one or more authentication methods. As long as one authentication method passes, you will not authenticate other methods. Usually, you can start two authentication methods: X 509 client certs and service accout tokens

  • Common Certifications:
  • Guide token: for example: authentication when a node joins: kubelet
  • Static token: a token stored in a file that can be directly loaded by the API server process. The contents of the file will be cached in memory by the API server;
  • Static password: the account and password token stored in the file that the API server process can load directly. The contents of the file will be cached in memory by the API server;
  • Serviceaccount token:
  • Openid connect token: oidc token,
  • OAuth 2 webhook token
  • Agent authentication, etc

Clients accessing k8s the API server mainly fall into two categories:

  • Kubectl: in the user’s home directory Kube / config stores the key related information of the client accessing the API server, so that when kubectl accesses k8s, it will automatically read the configuration file, initiate authentication to the API server, complete the operation request, and use the users accounts general account.
  • Pod: the process in the pod needs to access the API server. If it is accessed by a person or a script, the account used for such access is: useraccount; When pod connects to API server itself, the account used is serviceaccount, which is mostly used in production.
  • Kubectl sends the command to apiserver in HTTP mode, which is actually to add, delete, modify and query the URL.

    [[email protected] ~]# kubectl proxy --port=8888 &
    [[email protected] ~]# curl http://localhost:8888/api/v1/namespaces/default
    [[email protected] ~]# curl http://localhost:8888/apis/apps/v1/namespaces/default/deployments
  • The difference between the above two APIs is:
    API is a special link that can only be used by objects in the core V1 group.
    APIs is the fixed format name of the entry accessed by the general API

Serviceaccount token authentication

  • K8s automatically injects a serviceaccount token into each pod. In each namespace, a serviceaccount will automatically exist (in the charge of the serviceaccount admission controller) and will be shared and used by each pod in the space.
  • The authentication token is stored in a secret object in this space, which has three information in total:
    1.namespace
    2.ca.crt
    3.token
  • Resource definition format:
Apiversion: API Group and version to which V1 #serviceaccount belongs
Kind: serviceaccount # resource type ID
metadata:
  Name < string > # resource name
  Namespace < string > # serviceaccount is a namespace level resource
Automountserviceaccounttoken < Boolean > # whether to let pod mount API token automatically
Secrets < [] Object > # is a list of secret objects to be used by the pod running this SA
  API Group and version of the secret object referenced by apiversion < string > # can be omitted
  Kind < string > # refers to the type of resource referenced. Here, it refers to secret and can be omitted
  Name < string > # refers to the name of the secret object. Usually, only this field is given
  Namespace < string > # refers to the namespace to which the secret object belongs
  Uid < string > # refers to the identifier of the secret object;
Imagepullsecrets < [] Object > # refers to the list of secret objects used to download the container image in the pod. When talking about secret, it was mentioned that the pod is attached to the private warehouse secret. It is inconvenient to use in practice. Each pod needs to be attached separately. If you put it in the serviceaccount, you don't need to attach each pod separately
  Name < string > #docker registry type secret resource name

Example: view the default serviceaccount and secret of pod

[[email protected] ~]# kubectl get pod    
NAME                                 READY   STATUS    RESTARTS   AGE
centos-deployment-66d8cd5f8b-9x47c   1/1     Running   1          41h
demodb-0                             1/1     Running   0          17h
demodb-1                             1/1     Running   0          16h
  • By default, if no serviceaccount is specified, the default serviceaccount will be attached to the pod
[[email protected] ~]# kubectl describe  pod demodb-0 
Annotations:  <none>
...
    Mounts:
      /demodb/data from data (rw)
      /var/run/secrets/kubernetes. IO / serviceaccount from default token fsshk (RO) # default serviceaccount token
...
Volumes:
  data:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  data-demodb-0
    ReadOnly:   false
  Default token fsshk: # default serviceaccount token storage volume
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-fsshk  
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:          <none>
  • A default secret is automatically generated under each namespace
[[email protected] ~]# kubectl get secret
NAME                  TYPE                                  DATA   AGE
default-token-fsshk   kubernetes.io/service-account-token   3      51d   
harbor-tom            kubernetes.io/dockerconfigjson        1      11d
mysql-root-authn      Opaque                                2      11d
nginx-ssl-secret      kubernetes.io/tls                     2      11d
web-basic-authn       kubenetes.io/basic-auth               2      11d
[[email protected] ~]# kubectl get secret -n kube-system
NAME                                             TYPE                                  DATA   AGE
attachdetach-controller-token-bpprw              kubernetes.io/service-account-token   3      51d
bootstrap-signer-token-69hd8                     kubernetes.io/service-account-token   3      51d
bootstrap-token-hbjzpz                           bootstrap.kubernetes.io/token         5      14d
certificate-controller-token-26sn8               kubernetes.io/service-account-token   3      51d
clusterrole-aggregation-controller-token-hlb6c   kubernetes.io/service-account-token   3      51d
coredns-token-k6swp                              kubernetes.io/service-account-token   3      51d
cronjob-controller-token-449ng                   kubernetes.io/service-account-token   3      51d
daemon-set-controller-token-qb22n                kubernetes.io/service-account-token   3      51d
default-token-xjfpp                              kubernetes.io/service-account-token   3      51d
...
  • The three main types of information are displayed in encrypted form. 1 namespace、2. ca.crt、3. token
[ [email protected] -Master ~]# kubectl describe secret default token xjfpp - n Kube system # view secret details
Name:         default-token-xjfpp
Namespace:    kube-system   
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: default
              kubernetes.io/service-account.uid: a7cfad17-e87a-42dd-8f34-46181dd43b05

Type:  kubernetes.io/service-account-token

Data  
====
ca.crt:     1066 bytes
namespace:  11 bytes     
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6Ijh4bkpFMkMxV0FtZmxPTmxsV3ZhY3lIRnZiRjlaUnhFSXdHSnRGc21adUUifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJkZWZhdWx0LXRva2VuLXhqZnBwIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6ImRlZmF1bHQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiJhN2NmYWQxNy1lODdhLTQyZGQtOGYzNC00NjE4MWRkNDNiMDUiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6a3ViZS1zeXN0ZW06ZGVmYXVsdCJ9.ifUAhcEjhmSszILrjPkbmKAKuo6nDBPrmQTjz6HjBXw85eTsu-D5CCjGwSaVj7X6xqK3GTwcv-r8518pSv92rfbN5cc9FdpknJGjtuigCrksap1gHcqZvco3BM7KFEaTFpCaxiVvzp6YBh4pVmm4zAJGieE8964m3SwZqXUmf3VP3LyVDrYnlISQXoXy5oEXODe8694H1vwU3wuRmkwLOCV5QthTxFpx5siM7_KFkcBuG-pt0lTbf6d15OXk-WY6J3qkdbmLrJFaofAo-1tas6Fp7ziQnIAkG_lTrbXPHD-rHJf9v1PobVIVvlEe5hKc_V1tE36SEwpIYHb61DfWRw
  • The default mount path of pod is / var / run / secrets / kubernetes io/serviceaccount
[[email protected] authfiles]# kubectl exec -it demodb-0 -- /bin/sh
/demodb/data # cd /var/run/secrets/kubernetes.io/serviceaccount
/run/secrets/kubernetes.io/serviceaccount # ls
ca.crt     namespace  token
/run/secrets/kubernetes.io/serviceaccount # cat namespace 
/run/secrets/kubernetes.io/serviceaccount # cat ca.crt 
-----BEGIN CERTIFICATE-----
MIIC5zCCAc+gAwIBAgIBADANBgkqhkiG9w0BAQsFADAVMRMwEQYDVQQDEwprdWJl
cm5ldGVzMB4XDTIxMDYyODE3NDIxMFoXDTMxMDYyNjE3NDIxMFowFTETMBEGA1UE
AxMKa3ViZXJuZXRlczCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwQ
mCJJ0GuIDdzZa8XAJIy7BRUGBT0oI0lVuWc3PD25whr1MBRyUru0u0n7mKVQTzbY
0G8USHzwSnX51OoMpU5YwHK6WGLgJ6gdCfjAY6v12e7y+rvjOKYns6ljUf2MnaIL
nrCy1/u56Lnh1wCH1XkLECP539MFamYkRGxeS9FZlFcgLvJp43VX9V4IWQeumHd9
1abKVei/41qbbvyDU7l4l7klUmLUTGDlYpf1GPU/Jaom4QLRaEt2csYcNZ8J3yaY
GvOloGM150Rsx4vL8DWOqZcUUg/uXujKg1MfWRrD9KvqK1QdP92IE+l6nXUKY34r
voDCmOcL8J0nPyjbyf0CAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgKkMA8GA1UdEwEB
/wQFMAMBAf8wHQYDVR0OBBYEFOwi2wrUbuvVmbiV2rnnLtz0hsgcMA0GCSqGSIb3
DQEBCwUAA4IBAQBCFkEU4gyouDs4hG0pjdlrJRkDw1kKg1JV8m3CqcKUKmJBUT9H
9R8LaU2s/6yS5zX3VSdUNgF1V/hpjUJ6bSud9Xfnmbw8lHKUucUSIWU9a+TGTvkn
DqI8FcC8gKstUAwagxdRwj3KEy7HSAcbMXjKFSdAlQ2Qq7CG8vLXilurHhEEbrzq
unbuVjJ80gIWeeo23HkAbjOiTiSokN2AoGyGW9eS3bMLSJgMHzLtX80uWwS75jc3
2mMrYe59nzGIR2yY2zxkmmj6DOLoMQKyJlqPC2fGKyAv0N79QKAGl7JjbXzYvaV2
egWtCk0FHnfah9Fu+/P8pNtY8agSluneeHkL
-----END CERTIFICATE-----
/run/secrets/kubernetes.io/serviceaccount #