Security and RBAC Flashcards

What is the purpose of the `securityContext` field at the container level in a Pod spec?

Answer: To set security settings like runAsUser and allowPrivilegeEscalation

The container-level `securityContext` sets security parameters such as runAsUser, runAsNonRoot, readOnlyRootFilesystem, and allowPrivilegeEscalation.

Which command would you use to check what permissions a specific ServiceAccount has in Kubernetes?

Answer: kubectl auth can-i --as=system:serviceaccount::

The `kubectl auth can-i` command with the `--as` flag lets you impersonate a ServiceAccount to verify its permissions.

What is a 'subject' in the context of Kubernetes RBAC?

Answer: A user, group, or ServiceAccount that a RoleBinding targets

In RBAC, subjects are the entities (users, groups, or ServiceAccounts) that are granted permissions via RoleBindings or ClusterRoleBindings.

Which Kubernetes feature allows you to restrict egress and ingress traffic to/from Pods?

Answer: NetworkPolicy

NetworkPolicy resources define rules that control the allowed ingress and egress traffic for Pods based on labels and namespaces.

What does the `runAsNonRoot: true` setting in a Pod's securityContext enforce?

Answer: Prevents the container from running if its image would run as root

Setting `runAsNonRoot: true` causes the kubelet to validate that the container does not run as UID 0 (root), rejecting it if it would.

In Kubernetes, which group represents all authenticated users?

Answer: system:authenticated

The `system:authenticated` group is a built-in group that includes all authenticated users regardless of their identity.

What is the effect of binding a subject to the built-in 'cluster-admin' ClusterRole?

Answer: Grants full superuser access to all resources in the cluster

The 'cluster-admin' ClusterRole grants full superuser access, allowing any action on any resource in any namespace or at the cluster scope.