Kubernetes Security Concepts: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 38: Line 38:
* https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions
* https://kubernetes.io/docs/reference/access-authn-authz/rbac/#service-account-permissions
* https://docs.bitnami.com/kubernetes/how-to/configure-rbac-in-your-kubernetes-cluster/</font>
* https://docs.bitnami.com/kubernetes/how-to/configure-rbac-in-your-kubernetes-cluster/</font>
==Cluster Role==
==Cluster Role Binding==

Revision as of 21:26, 11 September 2019

Internal

Transport Security

Service Account

A service account provides an identity for processes that run in a pod. Pods that want to interact with the API Server will authenticate with a particular 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.

TODO:

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

Service Account Operations

Role Based Access Control (RBAC)

In Kubernetes, granting a role to an application-specific service account is a best practice to ensure that the application is operated in a specified scope.

TODO:

Cluster Role

Cluster Role Binding