- Provide an identity to Pods in the Cluster
- Stored in and managed by 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
- Scoped to a namespace
- 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.
- Service Accounts are compatible with RBAC controls.
- used for providing access to the Kubernetes APIs
- Pods have a token mounted on a volume that can be used to authenticate requests
- the 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 a 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.
2 type of accounts in Kubernetes:
- User Accounts (Human access) and
- Service Accounts (used by an app to interact with a clusters. Prometheus has an account used to pull metrics).
kubectl create serviceaccount <accountname>
kubectl create serviceaccount dashboard-sa
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: read-pods
namespace: default
subjects:
- kind: ServiceAccount
name: dashboard-sa # Name is case sensitive
namespace: default
roleRef:
kind: Role #this must be Role or ClusterRole
name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups:
- ''
resources:
- pods
verbs:
- get
- watch
- list