Kubernetes authorization

Service Account

A service account provides an identity for processes that run in a Pod.
When you create a pod, if you do not specify a service account, it is automatically assigned the default service account in the same namespace. If you get the raw json or yaml for a pod you have created (for example, kubectl get pods/ -o yaml), you can see the spec.serviceAccountName field has been automatically set.

default service account

Every namespace has a default service account resource called default.

Service Account Permissions

Grant a role to an application-specific service account (best practice)

This requires the application to specify a serviceAccountName in its pod spec, and for the service account to be created (via the API, application manifest, kubectl create serviceaccount, etc.).

kubectl create rolebinding my-sa-view \
  --clusterrole=view \
  --serviceaccount=my-namespace:my-sa \
  --namespace=my-namespace

Grant a role to the “default” service account in a namespace

If an application does not specify a serviceAccountName, it uses the “default” service account.
Note: Permissions given to the “default” service account are available to any pod in the namespace that does not specify a serviceAccountName.

kubectl create rolebinding default-view \
  --clusterrole=view \
  --serviceaccount=my-namespace:default \
  --namespace=my-namespace

Grant a role to all service accounts in a namespace

If you want all applications in a namespace to have a role, no matter what service account they use, you can grant a role to the service account group for that namespace.

For example, grant read-only permission within “my-namespace” to all service accounts in that namespace:

kubectl create rolebinding serviceaccounts-view \
  --clusterrole=view \
  --group=system:serviceaccounts:my-namespace \
  --namespace=my-namespace

Grant a limited role to all service accounts cluster-wide (discouraged)

If you don’t want to manage permissions per-namespace, you can grant a cluster-wide role to all service accounts.
For example, grant read-only permission across all namespaces to all service accounts in the cluster:

kubectl create clusterrolebinding serviceaccounts-view \
  --clusterrole=view \
 --group=system:serviceaccounts

Grant super-user access to all service accounts cluster-wide (strongly discouraged)

If you don’t care about partitioning permissions at all, you can grant super-user access to all service accounts.

kubectl create clusterrolebinding serviceaccounts-cluster-admin \
  --clusterrole=cluster-admin \
  --group=system:serviceaccounts

User accounts Vs Service accounts

When you (a human) access the cluster (for example, using kubectl), you are authenticated by the apiserver as a particular User Account (currently this is usually admin, unless your cluster administrator has customized your cluster). Processes in containers inside pods can also contact the apiserver. When they do, they are authenticated as a particular Service Account (for example, default).

Kubernetes distinguishes between the concept of a user account and a service account for a number of reasons:

• User accounts are for humans. Service accounts are for processes, which run in pods.
• User accounts are intended to be global. Names must be unique across all namespaces of a cluster, future user resource will not be namespaced. Service accounts are namespaced.
• Typically, a cluster’s User accounts might be synced from a corporate database, where new user account creation requires special privileges and is tied to complex business processes. Service account creation is intended to be more lightweight, allowing cluster users to create service accounts for specific tasks (i.e. principle of least privilege).
• …

Add-ons

Add-ons extend the functionality of Kubernetes.
For example

Calico is a secure L3 networking and network policy provider.
Flannel is an overlay network provider that can be used with Kubernetes.
Weave Net provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database.

Checking API Access

kubectl provides the auth can-i subcommand for quickly querying the API authorization layer. The command uses the SelfSubjectAccessReview API to determine if the current user can perform a given action, and works regardless of the authorization mode used.

kubectl auth can-i create deployments --namespace dev

RBAC Authorization

Role and ClusterRole

A Role can only be used to grant access to resources within a single namespace. Here’s an example Role in the “default” namespace that can be used to grant read access to pods:

A ClusterRole can be used to grant the same permissions as a Role, but because they are cluster-scoped, they can also be used to grant access to:

• cluster-scoped resources (like nodes)
• non-resource endpoints (like “/healthz”)
• namespaced resources (like pods) across all namespaces (needed to run kubectl get pods --all-namespaces, for example)

RoleBinding and ClusterRoleBinding

A role binding grants the permissions defined in a role to a user or set of users. It holds a list of subjects (users, groups, or service accounts), and a reference to the role being granted. Permissions can be granted within a namespace with a RoleBinding, or cluster-wide with a ClusterRoleBinding.

A RoleBinding or ClusterRoleBinding binds a role to subjects. Subjects can be groups, users or service accounts.
Service Accounts have usernames with the system:serviceaccount: prefix and belong to groups with the system:serviceaccounts: prefix.

RoleBinding

A RoleBinding may reference a Role in the same namespace. The following RoleBinding grants the “pod-reader” role to the user “jane” within the “default” namespace. This allows “jane” to read pods in the “default” namespace.

A RoleBinding may also reference a ClusterRole to grant the permissions to namespaced resources defined in the ClusterRole within the RoleBinding’s namespace. This allows administrators to define a set of common roles for the entire cluster, then reuse them within multiple namespaces.

ClusterRoleBinding

a ClusterRoleBinding may be used to grant permission at the cluster level and in all namespaces.

Privilege Escalation

A user can only create/update a role binding if they already have all the permissions contained in the referenced role (at the same scope as the role binding) or if they’ve been given explicit permission to perform the bind verb on the referenced role. For example, if “user-1” does not have the ability to list secrets cluster-wide, they cannot create a ClusterRoleBinding to a role that grants that permission.

reference

https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions