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

This is the last article in this series. Earlier, we learned about the basic concepts of access control and the specific operations of authentication and authorization. In this article, we will learn more about service account in access control.

There are concepts of user and service account in Kubernetes, which can be used to access resources. The user is associated with a key and certificate to authenticate API requests, using one of the configuration schemes to authenticate any requests initiated outside the cluster. The most common scenario is to make an authentication request through an X.509 certificate. For information about creating certificates and associating certificates with users, see the Kubernetes Authentication tutorial.

Keep in mind that Kubernetes does not maintain databases or configuration files for users and passwords. Instead, it wants to manage outside the cluster. Through the concept of an authentication module, Kubernetes can delegate authentication to a third party, such as OpenID or Active Directory.

Although X.509 certificates can be used for external requests for authentication, service account can be used to authenticate processes running in the cluster. In addition, the service account is associated with the pod that makes the internal call to API server.

Each Kubernetes installation has a default service account, which is associated with each running pod. Similarly, to enable pod to call internal API Server endpoints, there is a ClusterIP service called Kubernetes, which, together with the default service account, enables internal processes to call API endpoints.

Kubectl get serviceAccountsNAME SECRETS AGEdefault 1 122m kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT (S) AGEkubernetes ClusterIP 10.96.0.1 443/TCP 123m

Note that this service account points to the secret embedded in each pod. This secret contains the tokens required by API Server.

Kubectl get secretNAME TYPE DATA AGEdefault-token-4rpmv kubernetes.io/service-account-token 3 123m

When we started dispatching pod and accessing it, everything became clear. We will start a BusyBox-based pod using the curl command.

Kubectl run-I-- tty-- rm curl-tns-- image=radial/busyboxplus:curlkubectl run-- generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run--generator=run-pod/v1 or kubectl create instead.If you don't see a command prompt, try pressing enter. [root@curl-tns-56c6d54585-6v2xp:/] $

When we are in BusyBox shell, let's try to access the API Server endpoint.

[root@curl-tns-56c6d54585-6v2xp:/] $curl https://kubernetes:8443/api

Because the request lacks an authentication token, it does not produce any results. Let's take a look at how to retrieve tokens that can be embedded in the HTTP header.

As discussed earlier, tokens are installed in pod as a secret. Check / var/run/secrets/kubernetes.io/serviceaccount to find the token.

[root@curl-tns-56c6d54585-6v2xp:/] $cd / var/run/secrets/kubernetes.io/serviceaccount [root@curl-tns-56c6d54585-6v2xp:/tmp/secrets/kubernetes.io/serviceaccount] $lsca.crt namespace token

Let's set some environment variables to simplify the curl command.

CA_CERT=/var/run/secrets/kubernetes.io/serviceaccount/ca.crtTOKEN=$ (cat / var/run/secrets/kubernetes.io/serviceaccount/token) NAMESPACE=$ (cat / var/run/secrets/kubernetes.io/serviceaccount/namespace)

The following curl command requests services in the default namespace. Let's see if we can get a response from API Server.

[root@curl-tns-56c6d54585-6v2xp CA_CERT] $curl--cacert $CA_CERT-H "Authorization: Bearer $TOKEN"https://kubernetes/api/v1/namespaces/$NAMESPACE/services/"{" kind ":" Status "," apiVersion ":" v1 "," metadata ": {}," status ":" Failure " "message": "services is forbidden: User\" system:serviceaccount:default:default\ "cannot list resource\" services\ "in API group\"\ "in the namespace\" default\ "," reason ":" Forbidden "," details ": {" kind ":" services "}," code ": 403}

However, the default service account does not have sufficient permissions to retrieve services in the same namespace.

Keep in mind that Kubernetes follows a closed and open convention, which means that users and service account do not have any permissions by default.

To satisfy this request, we need to create a role binding that associates the default service account with the appropriate role. This step is similar to the way we bind the role to Bob, which gives him permission to list pod.

Exit pod and run the following command to create a role binding for the default service account.

Kubectl create rolebinding default-view\-clusterrole=view\-serviceaccount=default:default\-namespace=default rolebinding.rbac.authorization.k8s.io/default-view created

The above command associates the default service account with the cluster role view, which enables pod to list resources.

If you are curious to see all the available cluster roles, run the command: kubectl get clusterroles.

Let's start BusyBox pod again and visit API Server.

Kubectl run-I-- tty-- rm curl-tns-- image=radial/busyboxplus:curlkubectl run-- generator=deployment/apps.v1 is DEPRECATED and will be removed in a future version. Use kubectl run--generator=run-pod/v1 or kubectl create instead.If you don't see a command prompt Try pressing enter. [root@curl-tns-56c6d54585-2cx44:/] $CA_CERT=/var/run/secrets/kubernetes.io/serviceaccount/ca.crtTOKEN=$ (cat / var/run/secrets/kubernetes.io/serviceaccount/token) NAMESPACE=$ (cat / var/run/secrets/kubernetes.io/serviceaccount/namespace) curl--cacert $CA_CERT-H "Authorization: Bearer $TOKEN"https://kubernetes/api/v1/namespaces/$NAMESPACE/services/"{" kind ":" ServiceList "," apiVersion ":" v1 " Metadata: {"selfLink": "/ api/v1/namespaces/default/services/", "resourceVersion": "11076"}, "items": [{"metadata": {"name": "kubernetes", "namespace": "default", "selfLink": "/ api/v1/namespaces/default/services/kubernetes", "uid": "b715a117-6be1-4de0-8830-45bddcda701c" "resourceVersion": "151l", "creationTimestamp": "2019-08-13T09:45:27Z", "labels": {"component": "apiserver", "provider": "kubernetes"}}, "spec": {"ports": [{"name": "https" "protocol": "TCP", "port": 443," targetPort ": 8443}]," clusterIP ":" 10.96.0.1 "," type ":" ClusterIP "," sessionAffinity ":" None "} "status": {"loadBalancer": {}}]}

Feel free to create additional bindings for the default service account to check how RBAC extends to pod.

This concludes a series of articles on Kubernetes authentication and authorization, and we discuss the basic concepts of authentication, authorization, and Service account, which we hope will help you.

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.