Every Pod by default has Service Account configuration mounted inside it. When Pod communicates with Api-Server, it uses Service Account token. Service Account is used by containers running inside a Pod, to communicate with the Api-Server of the Kubernetes Cluster (see here). By default each Pod can communicate with Api-Server of the Cluster it is running on. If no Service Account is specified, it uses the default Service Account of its namespace.

kubectl get sa – command that shows all Service Accounts in the Cluster

Default Service Account has limited privileges. That is why sometimes custom Service Account(s) with more privileges must be created. Service Account(s) used by Pod are stored in the filesystem of every container of the Pod in run/secrets/kubernetes.io/serviceaccount folder. File named token of respective serviceaccount folder contains token value used for communicating with Api-Server. This is a script creating custom ServiceAccount. Service Account (if it is not default Service Account) should be explicitly denoted in yaml script via serviceAccountName: <name of Service Account> parameter.

More useful information about Service Accounts can be accessed here.

In Kubernetes Service Accounts are used for pods and underlying containers to communicate with Api-Server.

Security Context in Kubernetes

Whenever entering the Pod a user is getting root privileges. Usually it is not a good idea to give a Pod so many privileges, because it becomes possible for Pod to make changes on the Node it is running on. That is where Security Context comes into limelight. Here are some points to read about Security Context. A Security Context is a set of constraints applied to a container in order to achieve the following goals :

• Ensure a clear isolation between container and the underlying host it runs on
• Limit the ability of the container to negatively impact the infrastructure of other containers

This is an example of yaml file defining securityContext for one particular container. If a Pod contains more than one containers, then securityContext section can be defined above all containers to be applied to all.

In previous example securityContext was defined on user level. Next example shows how securityContext can be applied on group level to all containers, with user level constraints applied to every container.

Occasionally, it is necessary to customize how containers interact with the underlying security mechanisms present on the operating system of Kubernetes nodes. The SecurityContext attribute in a Pod specification allows for making these customizations. For this :

1. Create some users, groups and files on both worker nodes which can be used for testing
2. Create pods with access confined to users, groups created earlier

Examples of steps above are demonstrated here.