Your application running in a pod many to authenticate itself to gain access to cluster resources. That is the purpose of service accounts which we will cover in this lesson. We will start by explaining what service accounts are then we will see an example of how you configure service accounts, finally we'll touch on image pull secrets and how service accounts can help when you're working with the private container registry. Service accounts provide an identity to pods running in the cluster. Unlike users in Kubernetes which are managed by an external identity system and they are intended to be used by real people, service accounts are made for pods. Service accounts are also resources that are stored in and managed by the Kubernetes cluster.

Service accounts are namespace resources meaning they can only be used within one Kubernetes namespace and name of service accounts must be unique within the namespace but not across different namespaces. One of the main reasons for using service accounts is to utilize Role-Based Access Control or RBAC is securely mechanism built into Kubernetes. RBAC largely to define roles and associated permissions to access Kubernetes APIs and resources. For example, if your application needs to know the status of nodes in the cluster, our role allows you to grab those permissions. The same access control system is used to grab permissions to users in Kubernetes.

 A Kubernetes administrator would usually define their roles since it requires knowledge of Kubernetes APIs and small mistakes could compromise the entire cluster. The actual mechanics of a pod authenticating itself involve using an authentication token that is automatically mounted into the pods file system. That token can be used as an authentication header for request center to Kubernetes APIs server. Every namespace has a default service account that is named default. Every pod that doesn't specify service account automatically uses a default service account. The default service account doesn't have any additional permissions than an authenticated user, making it secured by default. Those permissions are mainly limited to discovering what API the cluster provides but does not grab permission to use them, thereby denying access to any cluster state. Let's go see how service accounts can be configured. 

You will work with service accounts first hand in the mastering Kubernetes pod configuration map if you are taking this course as part of the CKAD learning path. So this demo will just touch on a few key points. In a new cluster, the most interesting namespace from a service account perspective is keep system. The namespace reserves for system resources. Let's list the service accounts in Kube system. Because a lot of the pods in Kube system need access to different APIs and resources, there are many different service accounts. For example, cluster dns is provided by coredns and there is a service account for that. The default service account is also here as it would be in any other namespace. Just to get an idea of what a role looks like. Let's see the role that is bound to the coredns service account. In this case, it is actually a cluster role which means that it is not scoped to a specific namespace, instead, the role grabs permissions to all namespaces in the cluster. The cluster role is cloud system coredns and the described output gives the table showing the permissions granted. 

The role gives permissions to get nodes and to list and watch endpoints, namespaces, services, and pods. That makes sense, as a dns service needs to know when pods and services are created so it can create dns records for accessing them but no write permission is needed. So how can you associate a pod with the service account? Let's take a look at the output of a coredns pod to see that. The service account name field is what needs to be set to associate a non-default service account. You can also see above that in the volumes for the container that the token is mounted at the var/run/secrets/kubernetes.io/serviceaccount path and that's all for this demo. Just before we wrap up this lesson, I want to add a note about service accounts and image pull secrets. Image pull secrets come into play when you're using a private container registry for your container images. 

The way that you authenticate with the container registry so that you can pull an image into Kubernetes is by using image pull secrets. The secrets may be a docker registry server address user name and a password, for example, you can specify image pull secrets in pod specs directly but service accounts can also reference image pull secrets. Service accounts can provide both an authentication token and image pull secrets. It creates a nice separation of responsibilities when uses a service account for managing image pull secrets rather than hard coring your reference into pods specs. You can only modify the default service account to have image pull secrets so that any pod and a namespace can use images for your trusted registry without specifying a service account. That's all for this lesson where we covered the basic of service accounts. That they provide an identity to pods and in doing so, it enables Role Based Access Control for pods. 

By default, every namespace has a default service account and it does not have any permissions beyond that of an authenticated user. Then we saw some examples of service accounts in the Kube system namespace and that the service account name field in a pod specs is how to configure the service accounts of a pod. Lastly, we learned that service accounts can also provide a convenient way to store image pull secrets. The next lesson will teach you how to get the most out of Kubectl. There are useful tips if you plan to take the CKAD exam but also very useful in practice. Check it out when you are ready.