kubernetes(k8s) note authentication, authorization and admission control authentication ServiceAccount

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:
  • First, let's take a look at the initiation of Kubernetes API requests. The initiation of requests 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 a status code of 403 and also 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 (either) - > authorization (generally rbac and node) - > admission control (optional)

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 the API Server process can load directly. 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: the. kube/config in the user's home directory stores the key related information of the client accessing the API Server. In this way, 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 the pod connects to the API Server itself, the account used is ServiceAccount, which is mostly used in production.

  • kubectl sends commands to apiserver in the http mode, which is actually an operation of adding, deleting, modifying and querying URL s.

    [root@k8s-master ~]# kubectl proxy --port=8888 &
[root@k8s-master ~]# curl http://localhost:8888/api/v1/namespaces/default
[root@k8s-master ~]# curl http://localhost:8888/apis/apps/v1/namespaces/default/deployments
  • The difference between the above two APIs is:
    api, which 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 saved in a Secret object in this space, which has three information:
    1.namespace
    2.ca.crt
    3.token
  • Resource definition format:
apiVersion: v1 #API Group and version to which ServiceAccount belongs
kind: serviceAccount #Resource type identification
metadata:
  name <string> #Resource name
  namespace <string> # ServiceAccount is a namespace level resource
automountServiceAccountToken <boolean> # Do you want Pod to automatically mount API token
secrets <[]object> #A list of Secret objects to be used by the Pod running with this SA
  apiVersion <string> #The API Group and version to which the referenced Secret object belongs can be omitted
  kind <string> #The type of the referenced resource, here referred to as Secret, which can be omitted
  name <string> #The name of the referenced Secret object. Usually, only this field is given
  namespace <string> #The namespace to which the referenced Secret object belongs
  uid <string># Identifier of the referenced Secret object;
imagePullSecrets <[]object> # The referenced list of secret objects used to download the container image in the Pod mentioned that the Pod is attached to the private warehouse secret when talking about secret. It is inconvenient to use in practice. Each Pod needs to be attached separately. If it is placed in the serviceaccount, each Pod does not need to be attached separately
  name <string> #The name of the Secret resource of docker registry type

Example: view the default ServiceAccount and Secret of Pod

[root@k8s-master ~]# 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 mounted to the Pod
[root@k8s-master ~]# 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
[root@k8s-master ~]# 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
[root@k8s-master ~]# 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 encryption: 1. namespace, 2. ca.crt and 3. token
[root@k8s-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
[root@k8s-master 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 #

Keywords: Operation & Maintenance Kubernetes Container

Added by swordske on Wed, 01 Dec 2021 21:32:21 +0200

Popular Keywords

©2024 Programming VIP