Shulou(Shulou.com)06/02 Report--

This article is about k8s authentication in docker and the sample analysis of serviceaccount and RBAC. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

At present, RBAC is the most commonly used way of K8s authorization.

On k8s, a client initiates a request to apiserver with the following information:

1) username,uid,2) group,3) extra (additional information) 4) API5) request path, for example: http://127.0.0.1:8080/apis/apps/v1/namespaces/kube-system/d6) HTTP request action, such as get,post,put,delete,7) Http request action, such as get,list,create,udate,patch,watch,proxy,redirect,delete,deletecollection8) Rresource9) Subresource10) Namespace11) API group

K8s can support the coexistence of multiple versions.

In fact, the commands we issue to apiserver with kubectl are all in http mode.

K8s verification is divided into useraccount and serviceaccount.

You can use a proxy:

[root@master ~] # kubectl proxy-- port=8080 [root@master ~] # curl [root@master ~] # kubectl get deploy-n kube-systemNAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGEcoredns 22 22 220d [root@master ~] # curl http://127.0.0.1:8080/apis/apps/v1/namespaces/kube-system/deployments[root@master ~] # kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT (S) AGEkubernetes ClusterIP 10.96.0.1 443/TCP 20d [root@master ~] # kubectl describe svc kubernetesName: kubernetesNamespace: defaultLabels: component=apiserver provider=kubernetesAnnotations: Selector: Type: ClusterIPIP: 10.96.0.1Port: https 443/TCPTargetPort: 6443/TCPEndpoints: 172.16.1.100:6443Session Affinity: NoneEvents:

Above, we see that 10.96.0.1 is the address of kubernetes apiserver, which enables the external cluster to access the pod inside the cluster through 10.96.0.1, as well as the function of pod inside the cluster to access applications outside the cluster.

Authentication must be achieved as long as you access the apiserver. The authentication information is stored in pod.

[root@master ~] # kubectl explain pods.spec.serviceAccountName [root@master manifests] # kubectl create serviceaccount mysa-o yaml-- dry-run > mysa.yaml [root@master manifests] # cat mysa.yaml apiVersion: v1kind: ServiceAccountmetadata: creationTimestamp: null name: mysa

As we can see above, as long as it is kubectl create, as long as you add-o yaml, you can export the list file, so that we do not have to write the list file from beginning to end, but just produce one and change it, which is very good.

In addition, kubectl get can also export yaml format, as follows:

[root@master manifests] # kubectl get pods myapp-1-o yaml-exportapiVersion: v1kind: Podmetadata: creationTimestamp: null generateName: myapp- labels: app: myapp-pod controller-revision-hash: myapp-8598dd746f statefulset.kubernetes.io/pod-name: myapp-1 ownerReferences:-apiVersion: apps/v1 blockOwnerDeletion: true controller: true kind: StatefulSet name: myapp uid: a98ebc48-c24f-11e8-bb35-005056a24ecb selfLink: / api/v1/namespaces/default/pods/myapp-1spec : containers:-image: ikubernetes/myapp:v1 imagePullPolicy: IfNotPresent name: myapp ports:-containerPort: 80 name: web protocol: TCP resources: {} terminationMessagePath: / dev/termination-log terminationMessagePolicy: File volumeMounts:-mountPath: / usr/share/nginx/html name: myappdata-mountPath: / var/run/secrets/kubernetes.io/serviceaccount name: default-token-5r85r readOnly: true dnsPolicy: ClusterFirst hostname: Myapp-1 nodeName: node2 priority: 0 restartPolicy: Always schedulerName: default-scheduler securityContext: {} serviceAccount: default serviceAccountName: default subdomain: myapp-svc terminationGracePeriodSeconds: 30 tolerations:-effect: NoExecute key: node.kubernetes.io/not-ready operator: Exists tolerationSeconds: 300-effect: NoExecute key: node.kubernetes.io/unreachable operator: Exists tolerationSeconds: 300 volumes:-name: myappdata persistentVolumeClaim: claimName: myappdata-myapp-1-name: default-token-5r85r secret: DefaultMode: 420 secretName: default-token-5r85rstatus: phase: Pending qosClass: BestEffort

Make the above changes into our new configuration list.

Create serviceaccount [root@master manifests] # kubectl create serviceaccount adminserviceaccount/admin created [root@master manifests] # kubectl get saNAME SECRETS AGEadmin 1 2sdefault 1 20d [root@master manifests] # kubectl describe sa adminName: adminNamespace: defaultLabels: Annotations: Image pull secrets: Mountable secrets: admin-token-6jpc5Tokens: admin-token-6jpc5Events: [root@master manifests] # kubectl get secretNAME TYPE DATA AGEadmin-token-6jpc5 kubernetes.io/service-account-token 3 57s

If you see automatic, there will be an extra token.

Let's bind serviceaccount and pod with a configuration list.

[root@master manifests] # cat pod-sa-demo.yaml apiVersion: v1kind: Podmetadata: name: pod-sa-demo namespace: default labels: app: myapp tier: frontend annotations: zhixin.com/created-by: "cluster admin" spec: containers:-name: myapp image: ikubernetes/myapp:v1 ports:-name: http containerPort: 80 serviceAccountName: admin # this means that our pod uses custom authentication information admin [root@master manifests ] # kubectl apply-f pod-sa-demo.yaml pod/pod-sa-demo created create useraccount

Kubeconfig is a configuration file in the authentication format that clients use when connecting to apiserver.

[root@master manifests] # kubectl config view apiVersion: v1clusters cluster-cluster: certificate-authority-data: REDACTED server: https://172.16.1.100:6443 name: kubernetescontexts:- context: # context defines which cluster is accessed by which user. Cluster: kubernetes user: kubernetes-admin name: kubernetes-admin@kubernetescurrent-context: kubernetes-admin@kuberneteskind: Configpreferences: {} users:- name: kubernetes-admin user: client-certificate-data: REDACTED client-key-data: REDACTED

Certificate location:

[root@master manifests] # cd / etc/kubernetes/pki/ [root@master pki] # lsapiserver.crt apiserver.key ca.crt front-proxy-ca.crt front-proxy-client.keyapiserver-etcd-client.crt apiserver-kubelet-client.crt ca.key front-proxy-ca.key sa.keyapiserver-etcd-client.key apiserver-kubelet-client.key etcd front-proxy-client.crt sa.pub

Example:

1. Make a private key

[root@master pki] # cd / etc/kubernetes/pki [root@master pki] # (umask 077; openssl genrsa-out zhixin.key 2048) Generating RSA private key, 2048 bit long modulus.+++.+++e is 65537 (0x10001)

Parentheses mean sub-shell.

2. Generate a certificate based on the private key

CN is the name of the user's account.

[root@master pki] # openssl req-new-key zhixin.key-out zhixin.csr-subj "/ CN=zhixin"

-subj: replace or specify the personal information of the certificate applicant

3. Sign the certificate

[root@master pki] # openssl x509-req-in zhixin.csr-CA ca.crt-CAkey ca.key-CAcreateserial-out zhixin.crt-days 365Signature oksubject=/CN=zhixinGetting CA Private Key

-days: indicates the expiration time of the certificate

X509: generate a certificate in x509 format

4. View the certificate content

[root@master pki] # openssl x509-in zhixin.crt-text-nooutCertificate: Data: Version: 1 (0x0) Serial Number: ab:45:1b:b3:92:32:59:ae Signature Algorithm: sha256WithRSAEncryption Issuer: CN=kubernetes # Certificate signatory Validity # validity period Not Before: Sep 28 08:01:20 2018 GMT Not After: Sep 28 08:01: 20 2019 GMT Subject: CN=zhixin # use this account to log in to k8s Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:bf:e5:b1:80:1a:a6:d1:24:ca:b8:75:a1:71:08: d2:ba:43 : ee:53:a1:10:b5:7a:83:e7:8b:06:65:c7: 8a:07:02:ca:cc:8f:5c:94:a9:7a:10:24:f6:41:a0: c6:fe:5f:21:59:21:e7:72:30:12:38:89:85:78:54: c1:15:c4 : 13:33:43:9c:94:c0:dc:99:e9:f0:44:7e: 35:66:cd:e0:d9:0c:82:dc:b3:73:ee:ea:47:9e:5e: e5:bf:0b:45:fb:a3:cf:59:67:ae:13:31:9c:dc:b6: 78:da:b2 : 7e:c0:7e:c2:30:c5:fd:ea:6f:94:fa:81: 19:9f:71:9c:cf:60:07:5b:fa:0d:c0:6f:2c:b4:e0: 42:d6:6d:d3:39:23:2b:f7:ad:cc:21:f8:df:89:ff: 6e:45:59 : 1f:5d:db:aa:fa:07:ef:fc:b3:7e:3d:b1: dd:3e:be:5e:43:de:8f:e2:ea:aa:ec:6c:48:df:2f: 2e:20:61:e3:5c:6a:37:3e:2b:32:e5:1a:ad:35:88: d6:d2:db : aa:26:5d:cb:67:0a:65:9e:d4:79:76:92: 9a:41:fb:df:db:85:1a:ea:5e:ff:bb:7b:2f:01:10: 9f:8e:9c:a1:fe:ae:ac:9d:43:02:40:01:f7:d6:da: bf:5a:99 : ba:d0:bf:ea:53:1e:f5:51:06:9c:ac:6f: 32:43 Exponent: 65537 (0x10001) Signature Algorithm: sha256WithRSAEncryption 91:43:cd:36:ad:88:17:a1:81:9f:8f:ad:9b:c5:41:d7:de:aa: 6a:f0:3a:00:f2:d7:9b:0e:89:bc : 51:73:cc:4f:10:85:13:70: aa:d1:67:f8:f3:a1:6b:83:ff:99:76:7f:14:a5:b4:82:fb:1b: fb:cf:d5:fc:b0:2f:ff:68:c4:b1:c0:ee:f9:6b:41:ea:0a:96: 2f:55:1d:d7:77:f8:70:a6:15:a4 : b6:e7:6d:93:61:2e:ac:7a: 10:70:fa:f7:43:da:56:f2:d0:e9:6b:01:72:73:2d:65:ea:4d: c4:3b:46:2d:1b:ad:f8:1f:eb:71:88:35:51:2a:dc:3a:36:fe: 63:bb:28:ee:d2:a0:d4:e0:14:95 : 10:96:20:2e:f3:75:12:eb: 05:8e:34:a1:dc:74:19:a5:76:0f:f2:bd:f3:56:aa:c9:40:51: c7:bd:1f:1f:c1:ec:a5:98:c8:b8:1d:07:67:fa:1c:a0:a3:1f: d3:ba:cb:09:52:9a:e7:59:39:ce : c8:ef:01:c2:4b:98:ff:05: 12:bf:69:36:0e:a6:a9:f6:40:34:28:36:0d:1b:76:31:b4:96: 6e:09:33:8e:d5:0a:96:77:dd:41:b3:29:db:d5:5e:fa:05:f7: e7:90:5d:79:6d:a9:59:20:60:0f : fe:d5:b6:38:6c:1a:ee:51: 66:c3:9b:4b

[root@master pki] # kubectl config set-credentials zhixin-client-certificate=zhixin.crt-client-key=zhixin.key-embed-certs=trueUser "zhixin" set.

Embed-certs: means to hide user information.

[root@master pki] # kubectl config viewapiVersion: v1clusters cluster: certificate-authority-data: REDACTED server: https://172.16.1.100:6443 name: kubernetescontexts:- context: cluster: kubernetes user: kubernetes-admin name: kubernetes-admin@kubernetescurrent-context: kubernetes-admin@kuberneteskind: Configpreferences: {} users:- name: kubernetes-admin user: client-certificate-data: REDACTED client-key-data: REDACTED- name: zhixin user: client-certificate-data : REDACTED client-key-data: REDACTED [root@master pki] # kubectl config set-context zhixin@kubernetes-- cluster=kubernetes-- user=zhixinContext "zhixin@kubernetes" created. [root@master pki] # kubectl config viewapiVersion: v1clusters cluster: certificate-authority-data: REDACTED server: https://172.16.1.100:6443 name: kubernetescontexts:- context: cluster: kubernetes user: kubernetes-admin name: kubernetes-admin@kubernetes- context: cluster: kubernetes user: zhixin name: zhixin@ Kubernetescurrent-context: kubernetes-admin@kuberneteskind: Configpreferences: {} users:- name: kubernetes-admin user: client-certificate-data: REDACTED client-key-data: REDACTED- name: zhixin user: client-certificate-data: REDACTED client-key-data: REDACTED

I can see zhixin's name in contexts.

6. Switch to zhixin user login k8s

[root@master pki] # kubectl config use-context zhixin@kubernetesSwitched to context "zhixin@kubernetes". [root @ master pki] # kubectl get podsNo resources found.Error from server (Forbidden): pods is forbidden: User "zhixin" cannot list pods in the namespace "default"

It is seen above that the get pods Times is wrong because the user zhixin@kubernetes does not have manager privileges.

7. Switch back to k8s administrator

[root@master pki] # kubectl config use-context kubernetes-admin@kubernetesSwitched to context "kubernetes-admin@kubernetes".

8. Set up a new k8s cluster

[root@master] # kubectl config set-cluster mycluster-kubeconfig=/tmp/test.conf-server= "https://127.0.0.1:6443"-certificate-authority=/etc/kubernetes/pki/ca.crt-embed-certs=trueCluster" mycluster "set

.-- kubeconfig: specify the location of the authentication file. If not specified, it will be located at ~ / .kube/config by default.

-- embed-certs=true indicates that the certificate information is hidden

As you can see, we have created a new K8s cluster called mycluster.

[root@master ~] # kubectl config view-- kubeconfig=/tmp/test.conf apiVersion: v1clusterscluster: certificate-authority-data: REDACTED server: https://127.0.0.1:6443 name: myclustercontexts: [] current-context: "" kind: Configpreferences: {} users: [] RBAC (role-based access control)

Rbac:role based ac, that is, we add the user to the role so that the user has the permissions of the role.

In K8s, everything is an object.

Object_URL: / apis///namespaces// [OJJECT _ ID]

RBAC binds user to role through rolebinding. The role is set based on namespace, which means that the user can only access pod resources under the specified namespace.

If user is bound to clusterrole through clusterrolebind, then the user breaks through the restrictions of namespace and has cluster-level permissions, that is, this user can access all pod under the namespace under this cluster.

However, we can also use rolebinding to bind user to clusterrole. In the figure above, we bind user1 to clusterrole through rolebinding, but we know that rolebinding is limited to namespace, so user1 is limited to namespace, not the entire cluster.

[root@master ~] # kubectl create role pods-reader-- verb=get,list,watch-- resource=pods Note: if you want to grant all permissions, you can use * to indicate [root@master ~] # kubectl create role pods-reader-- verb=get,list Watch-- resource=pods-- dry-run-o yamlapiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata: creationTimestamp: null name: pods-readerrules:- apiGroups: "" resources:-pods verbs:-get-list-watch [root@master ~] # kubectl get roleNAME AGEpods-reader 7s [root@master] # kubectl describe role pods-readerName: pods-readerLabels: Annotations: PolicyRule: Resources Non-Resource URLs Resource Names Verbs- -pods [] [get list watch] [root@master ~] # kubectl create rolebinding zhixin-read-pods-- role=pods-reader-- user=zhixinrolebinding.rbac.authorization.k8s.io/zhixin-read-pods created [root@master ~ ] # kubectl create rolebinding zhixin-read-pods-- role=pods-reader-- user=zhixin-o yaml-- dry-runapiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata: creationTimestamp: null name: zhixin-read-podsroleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: pods-readersubjects: # is the referenced user-apiGroup: rbac.authorization.k8s.io kind: User name: zhixin [root@master ~] # kubectl explain rolebinding [root@master ~] # kubectl describe rolebinding zhixin-read-podsName : zhixin-read-podsLabels: Annotations: Role: Kind: Role Name: pods-readerSubjects: Kind Name Namespace-User zhixin [root@master ~] # kubectl config use-context zhixin@kubernetesSwitched to context "zhixin@kubernetes". [root @ master ~] # kubectl get podsNAME READY STATUS RESTARTS AGEclient 0/1 Error 0 18dfilebeat-ds-bn7wf 0/1 InvalidImageName 0 4dfilebeat-ds-vd287 0/1 InvalidImageName 0 3dliveness-httpget-pod 1/1 Running 7 11dmyapp-0 1/1 Running 0 23h

Above we see that the zhixin user we established earlier does not have get pods privileges, but this time I added it to pods-reader role, so I have pods-reader role permissions.

[root@master] # kubectl get pods-n kube-systemNo resources found.Error from server (Forbidden): pods is forbidden: User "zhixin" cannot list pods in the namespace "kube-system

However, zhixin users do not have access to kube-system because role does not have access to this namespace, but only to default namespaces.

Rolebinding is only valid for namespace.

Let's switch back to the administrator.

[root@master ~] # kubectl config use-context kubernetes-admin@kubernetesSwitched to context "kubernetes-admin@kubernetes".

Let's define another clusterrole.

[root@master] # kubectl create clusterrole cluster-reader-- verb=get,list,watch-- resource=podsclusterrole.rbac.authorization.k8s.io/cluster-reader created [root@master] # kubectl create clusterrole cluster-reader-- verb=get,list Watch-- resource=pods-o yaml-- dry-runapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: creationTimestamp: null name: cluster-readerrules:- apiGroups: "" resources:-pods verbs:-get-list-watch [root@master ~] # kubectl explain clusterrole [root@master] # kubectl get rolebindingNAME AGEzhixin-read-pods 46m [root@master ~] # kubectl delete rolebinding zhixin-read-podsrolebinding.rbac.authorization.k8s.io "zhixin-read-pods" deleted

Let's test to add user zhixin to clusterrole:

[root@master ~] # kubectl create clusterrolebinding zhixin-read-all-pods-- clusterrole=cluster-reader-user=zhixin clusterrolebinding.rbac.authorization.k8s.io/zhixin-read-all-pods created [root@master ~] # kubectl get clusterrolebinding | grep readzhixin-read-all-pods 2m [root@master ~] # kubectl describe clusterrolebinding zhixin-read-all-podsName: zhixin-read-all-podsLabels: Annotations: Role: Kind: ClusterRole Name: cluster-readerSubjects: Kind Name Namespace-User zhixin [root@master ~] # kubectl config use-context zhixin@kubernetesSwitched to context "zhixin@kubernetes". [root @ master ~] # kubectl get podsNAME READY STATUS RESTARTS AGEclient 0 Error 0 18dfilebeat-ds-bn7wf 0 21dcoredns-78fcdf6894-dkkfq 1 InvalidImageName 0 4d [root@master ~] # kubectl get pods-n kube-systemNAME READY STATUS RESTARTS AGEcoredns-78fcdf6894-2l2cf 1 21dcoredns-78fcdf6894-dkkfq 1 Running 17 21dcoredns-78fcdf6894-dkkfq 1 Running 16 21D

It can be seen that after we bind the user zhixin to clusterrole, the user has permissions for all namespaces. Because cluserrolebinding is for clusters, while rolebinding is only for namespace.

Let's test another one to bind the user to cluserrole with rolebinding to see what the effect is:

[root@master ~] # kubectl config use-context kubernetes-admin@kubernetesSwitched to context "kubernetes-admin@kubernetes". [root @ master ~] # kubectl delete clusterrolebinding zhixin-read-all-podsclusterrolebinding.rbac.authorization.k8s.io "zhixin-read-all-pods" deleted [root@master ~] # kubectl create rolebinding zhixin-read-pods-clusterrole=cluster-reader-user=zhixin rolebinding.rbac.authorization.k8s.io/zhixin-read-pods created [root@master ~] # kubectl describe rolebinding zhixin-read-podsName: Zhixin-read-podsLabels: Annotations: Role: Kind: ClusterRole Name: cluster-readSubjects: Kind Name Namespace-User zhixin [root@master ~] # kubectl config use-context zhixin@kubernetesSwitched to context "zhixin@kubernetes". [root @ master ~] # kubectl get podsNAME READY STATUS RESTARTS AGEclient 0 Error 0 18dfilebeat-ds-bn7wf 0 kube- 1 InvalidImageName 0 4dfilebeat-ds-vd287 0 kube- 1 InvalidImageName 0 3dliveness-httpget-pod 1 pound 1 Running 7 11d [root@master ~] # kubectl get pods-n kube- SystemNo resources found.Error from server (Forbidden): pods is forbidden: User "zhixin" cannot list pods in the namespace "kube-system"

As you can see, when clusterrole is bound with rolebinding, it is downgraded to the namespace where rolebinding is located.

[root@master] # kubectl get clusterrole admin-o yaml resources:-pods-pods/attach-pods/exec-pods/portforward-pods/proxy verbs:-create-delete-deletecollection-get-list-patch-update-watch [root@master] # kubectl create rolebinding default-nameespace-admin-- clusterrole=adin-- user=zhixinrolebinding.rbac.authorization.k8s.io/default-nameespace-admin created

In this way, we set zhixin as the administrator of default namespaces rather than other namespaces. This is the ability to bind clusterrole with rolebinding.

[root@master] # kubectl get clusterrolebinding cluster-admin-o yaml- apiGroup: rbac.authorization.k8s.io kind: Group name: system:masters [root@master pki] # openssl x509-in. / apiserver-kubelet-client.crt-text-noout Subject: O=system:masters, CN=kube-apiserver-kubelet-client

See that the system:masters group has administrator privileges

Thank you for reading! On "docker K8s authentication and serviceaccount, RBAC example analysis" this article is shared here, I hope the above content can be of some help to you, so that you can learn more knowledge, if you think the article is good, you can share it out for more people to see it!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.