I'm struggling to understand what the purpose it serves?
For example in the following pod definition:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
serviceAccountName: build-robotWhen does the service account "matter"? In what interactions is it involved in?
https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/ explains how to set a non default one, but doesn't really mention what effect / interactions are changed - or why you would need to do this?
The only hint it really gives is this section:
Processes in containers inside pods can also contact the apiserver. When they do, they are authenticated as a particular Service Account (for example, default).
Which makes no sense what so ever. How does a arbitrary process magically become "authenticated" when it sends an HTTP request to the kubernetes API server?
Are there security benefits? If so what are they?
api-server understands two types of requests: authenticated and unauthenticated. Then, the authenticated requests can be authorized or not authorized.
A Service Account, a User or a Group (group of users) are objects containing certain permissions to interact with api-server.
You would use User or Group to give access to one individual or a group of people, to interact with api-server; mostly through kubectl. You can also curl the api-server endpoint though, as RESTful API, with the certificates.
But when you need a micro service (a pod) to interact with api-server, you need to specify a Service Account; also with all the necessary permissions.
All the permissions are given through RBAC rules.
Conclusion: You would create a User or Group and give it certain permissions to interact with api-server as person.
You would create a Service Account, and give it certain permissions, if you'd want the pod to interact with api-server as server (not as person).
From my experience, the ServiceAccount is required when you have RBAC active in your cluster (you should!) and your Pod has to communicate with the Kubernetes API.
Let's assume you have a pod that uses the Kubernetes Client to extend the kubernetes behavior. For example, you can send a message on Slack every time a Kubernetes Node joins the cluster. In order to allow the program running in your Pod to interact with the Kubernetes API, you have to pass a certificate. The ServiceAccount does that for you. And based on the ServiceAccount you use you can limit permissions.
Almost like in the AWS world an EC2 gets authentication to the AWS API via IAM Role and EC2 Profile.
It relates to the https://kubernetes.io/docs/concepts/policy/pod-security-policy/
The fact that the documentation makes no mention of this is really surprising.
Pod which need to interact with Kubernetes API Server needs a service account to authenticate to Kubernetes API Server.
To communicate with the API server, a Pod uses a ServiceAccount containing an authentication token. Roles (e.g: the right to list all the Pods within a given namespace), or ClusterRole (eg: the right to read all the Secrets within the entire cluster), can then be bound to this ServiceAccount. Respectively with a RoleBinding or a ClusterRoleBinding, so the ServiceAccount is authorized to perform those actions.
A lot of applications that run in the cluster (read: running in Pods), need to communicate with the API server. Among them are the processes running within the Control Plane (scheduler, controller manager, proxy, etc.), as well as all the applications that need to perform some form of administration for the cluster such as controllers which manages custom resources.