K8s Security
"Controlling Access to the Kubernetes API"
Authentication
"Configure Service Accounts for Pods"
Anonymous access can also be enabled.
Users are not created by the API, and should be managed by an external system.
One or more Authenticator Modules are used: x509 Client Certs static token, bearer or bootstrap token; static password file; service account and OpenID connect tokens. Each is tried until successful, and the order is not guaranteed.
authentication mechanisms. Kubernetes Documentation authentication .
--basic-auth-file
--oidc-issuer-url
--token-auth-file
--authorization-webhook-config-file
Authorisation
three main authorisation modes
kube-apserver startup options:
--authorization-mode=Node,RBAC
--authorization-mode=Webhook
Summary of the RBAC process, typically done by the cluster admin:
Determine or create namespace for the subject
Create certificate credentials for the subject
Set the credentials for the user to the namespace using a context
Create a role for the expected task set
Bind the user to the role
Verify the user has limited access
Admission controllers
Dynamic Admission Control p
enable/disable admission plugins
**--enable-admission-plugins=NamespaceLifecycle,LimitRanger
--disable-admission-plugins=PodNodeSelector**
Security Contexts - limitations for containers and pods
Pod security standards:
Privileged - No restrictions from this policy.
Baseline . - Minimal restrictions. Does not allow known privilege escalations.
Restricted .- Most restricted policy. Follows current pod hardening best practices.
Network Policy
TLS
- "Kubernetes the Hard Way"