Running applications in Kubernetes comes with a shared responsibility between developers and ops folks to ensure that attack vectors are minimized, least-privileges principles are followed, and access to resources is clearly defined. In this chapter, we will present recipes that you can, and should, use to make sure your cluster and apps run securely. The recipes in this chapter cover:
The role and usage of service accounts
Role-Based Access Control (RBAC)
Defining a pod’s security context
You want to provide an application with a unique identity in order to control access to resources on a fine-grained level.
Create a service account and use it in a pod specification.
To begin, create a new service account called
myappsa and have a closer look at it:
$ kubectl create serviceaccount myappsa serviceaccount "myappsa" created $ kubectl describe sa myappsa Name: myappsa Namespace: default Labels: <none> Annotations: <none> Image pull secrets: <none> Mountable secrets: myappsa-token-rr6jc Tokens: myappsa-token-rr6jc $ kubectl describe secret myappsa-token-rr6jc Name: myappsa-token-rr6jc Namespace: default Labels: <none> Annotations: kubernetes.io/service-account.name=myappsa kubernetes.io/service-account.uid=0baa3df5-c474-11e7-8f08... Type: kubernetes.io/service-account-token Data ==== ca.crt: 1066 bytes namespace: 7 bytes token: eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9 ...
You can use ...