Kubernetes Security Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 25: Line 25:
kubectl --as=system:serviceaccount:<namespace>:<service-account-name> -n <namespace> ...
kubectl --as=system:serviceaccount:<namespace>:<service-account-name> -n <namespace> ...
</syntaxhighlight>
</syntaxhighlight>
Also see: {{Internal|Kubernetes_Pod_and_Container_Concepts#Pods_and_Service_Accounts|Pod Service Account}}


==Service Account Full Name==
==Service Account Full Name==

Revision as of 03:51, 5 September 2020

Internal

Transport Security

User

Users are sometimes referred to as "users accounts". The Kubernetes resource is "User".

Group

Service Account

https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/
https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/

Processes in containers inside pods can contact the API server, and they need an identity when doing so. A service account provides the identity for processes that run in a the pod. Processes will authenticate using the identity provided by the service account. By default, in absence of specific configuration, the pods will authenticate as the default service account in the namespace they are running in. A specific service account name can be specified in the pod manifest - also see Non-Default Service Accounts below.

The credentials (token) for a service account is placed into the filesystem of each container of the pod at /var/run/secrets/kubernetes.io/serviceaccount/ca.crt and by default is auto-mounted. In Kubernetes 1.6+ it can be opted out of auto-mounting by setting automountServiceAccountToken in the service account manifest.The default namespace to be used for namespaced API operations is placed on the filesystem of each container of the pod at /var/run/secrets/kubernetes.io/serviceaccount/namespace. Service accounts are rendered in logs using their full name (e.g. "system:serviceaccount:blue:default).

kubectl operations can be conducted under the identity of a specific service account using kubectl --as option:

kubectl --as=system:serviceaccount:<namespace>:<service-account-name> -n <namespace> ...

Also see:

Pod Service Account

Service Account Full Name

Service accounts can be referred to using their full "system:serviceaccount:<namespace>:<account-name> (e.g. "system:serviceaccount:blue:default).

Default Service Account

Each namespace comes with a default service account:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
  namespace: default
secrets:
- name: default-token-dddkl

A pod whose service account was not explicitly configured will run with the default service account for its namespace, its configuration is equivalent with:

apiVersion: v1
kind: Pod
spec:
  containers:
  - name: [...]
    [...]
  serviceAccountName: default
[...]

The a specific service account can be configured as such:

apiVersion: v1
kind: Pod
spec:
  containers:
  - name: [...]
    [...]
  serviceAccountName: something
[...]

Non-Default Service Accounts

To use a non-default service account, set spec.serviceAccountName field of the pod manifest. The service account has to exist at the time the pod is created, or it will be rejected. If the pod was already created, the service account cannot be updated.

Service Account Operations

Role Based Access Control (RBAC)

Kubernetes Role Based Access Control (RBAC) Concepts

Pod Security Policies

Pod Security Policy Concepts

Cluster Administrator

Controlling Access to the Kubernetes API

https://kubernetes.io/docs/reference/access-authn-authz/controlling-access/