Security & Policy Knowledge

Role-Based Access Control regulates access to Kubernetes resources. It uses Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings to decide which subjects can perform which verbs on which resources.

A Role is namespace-scoped. A ClusterRole is cluster-scoped and can grant access to cluster resources, or it can be reused across namespaces through RoleBindings. Use the narrowest scope that satisfies the need.

A Role grants permissions within one namespace. A ClusterRole grants cluster-scoped permissions or reusable namespaced permissions. A RoleBinding grants a Role or ClusterRole inside one namespace. A ClusterRoleBinding grants a ClusterRole across the cluster.

A ServiceAccount is a Kubernetes identity used by Pods and controllers to authenticate to the Kubernetes API. RBAC bindings decide what that identity can do.

If a Pod does not specify serviceAccountName, it uses the default ServiceAccount in its namespace. This is convenient but often too broad or too anonymous for production workloads.

Use kubectl exec -it <pod> -- ls /var/run/secrets/kubernetes.io/serviceaccount. Newer clusters may use projected bound tokens, but this path commonly contains token, ca.crt, and namespace files when automounting is enabled.

Use kubectl auth can-i <verb> <resource> --as=<subject> -n <namespace>. For a ServiceAccount, use --as=system:serviceaccount:<namespace>:<name>. This is faster and safer than guessing from YAML.

Use kubectl auth can-i --as=system:serviceaccount:<ns>:<sa> '*' '*' for a broad check, and repeat with namespace scope where relevant. For safer review, test specific verbs and resources the workload actually needs.

The default ServiceAccount is too generic. Dedicated accounts make permissions auditable and minimal. Bind only the verbs and resources the workload needs, and avoid mounting tokens when the app does not call the API.

Pod Security Admission is a built-in admission controller that applies Pod Security Standards to namespaces. The main levels are privileged, baseline, and restricted, and they can be enforced, warned, or audited.

A Secret is a Kubernetes object for sensitive values such as passwords, tokens, keys, and certificates. Values are base64-encoded in manifests, and additional protections such as RBAC, encryption at rest, and external secret systems are often needed.

Base64 is reversible encoding, not cryptographic protection. Anyone who can read the encoded value can decode it. Treat base64 Secret data as sensitive plaintext.

They are base64-encoded in manifests, not inherently encrypted. In the API datastore they require encryption at rest to protect stored values. Also restrict RBAC access, avoid logging secret data, and prefer external secret systems where appropriate.

Configure an encryption provider in the API server encryption config file, then ensure the API server starts with that config. Existing Secrets may need to be rewritten so they are stored with the new provider.

A PodSecurityContext defines security settings that apply to all containers in a Pod, such as runAsUser, runAsGroup, fsGroup, SELinux options, supplemental groups, and seccomp defaults.

A container-level securityContext applies to one container and can override or add settings such as capabilities, privileged mode, readOnlyRootFilesystem, allowPrivilegeEscalation, runAsUser, and seccompProfile.

It gives the container broad host-level privileges and weakens container isolation. It is extremely risky for application workloads and should be limited to tightly controlled node-level components when unavoidable.

Linux capabilities are fine-grained privileges such as NET_ADMIN or SYS_TIME that can be added or dropped from containers. A safer pattern is to drop all capabilities and add back only the specific capability the container needs.

seccomp restricts the system calls available to a container, reducing kernel attack surface. The RuntimeDefault profile is a strong baseline for many workloads, with custom profiles reserved for special cases.

It applies built-in Pod security levels to namespaces: privileged, baseline, and restricted. It can enforce, warn, or audit. It helps prevent risky settings such as privileged containers, host namespaces, unsafe capabilities, and root execution patterns.

NetworkPolicy restricts Pod ingress and egress traffic, acting like a cluster firewall for selected Pods. Enforcement depends on the CNI, and policies are additive allow rules once a Pod is selected.

Traffic for the selected direction is blocked unless another NetworkPolicy explicitly allows it. Default-deny is useful, but remember to allow DNS, ingress controller traffic, health checks, and required dependencies.

They limit Pod ingress and egress paths. A default-deny policy plus explicit allows reduces lateral movement. The policy must be supported by the CNI and must account for DNS, health checks, ingress controllers, and required external dependencies.

imagePullPolicy: Always tells kubelet to check the registry whenever the Pod starts. It is useful with mutable tags, but immutable tags or digests are safer for repeatable releases.

Image signing verifies image authenticity and integrity before workloads run. Admission policy can require trusted signatures, helping prevent untrusted or tampered images from being deployed.

Check registry source, tag immutability, digest pinning, vulnerability scan results, base image age, SBOM, signature or attestation, and whether admission policy enforces allowed registries or signed images.

With TLS termination, TLS ends at the load balancer or ingress controller, which can inspect HTTP routing data and forward plain or re-encrypted traffic. With TLS passthrough, encrypted traffic is forwarded directly to the backend Pod or Service.

Authentication proves who the caller is. Authorization decides whether that identity can perform a verb on a resource. Admission then applies additional policy after authorization but before persistence.

A user with permission to create Pods may mount a Secret into a Pod and read it from the container, or exec into an existing Pod that already has it. Protect both Secret access and workload creation/exec permissions.