Task 2.2: Security

• AAuthorization, then authentication, then admission control

  Incorrect

  Authorization decides what an identified user may do, so it needs the result of authentication first.

• BAdmission control, then authentication, then authorization

  Incorrect

  Admission controllers act on requests that are already authenticated and authorized.

• CAuthentication, then authorization, then admission control

  Correct

  The request is authenticated first, then authorized for the action, and only then passed to admission controllers such as webhooks.

• DAuthentication, then admission control, then authorization

  Incorrect

  Admission comes last; a request that is not authorized never reaches it.

Every API request goes through authentication, authorization and then admission control; the webhook in the scenario is an admission controller.

• AOne ClusterRole, plus a ClusterRoleBinding for each team

  Incorrect

  A ClusterRoleBinding grants the permissions across all namespaces, which is far more than each team should get.

• BOne ClusterRole, plus a RoleBinding to it in each team's namespace

  Correct

  A RoleBinding can reference a ClusterRole and grants its permissions only within the RoleBinding's namespace, so one definition serves every team.

• COne Role in the default namespace, referenced by RoleBindings in the teams' namespaces

  Incorrect

  A RoleBinding can reference a Role only in its own namespace, so a Role in default cannot be reused elsewhere.

• DA ServiceAccount per team bound to the cluster-admin ClusterRole

  Incorrect

  cluster-admin grants every action everywhere; it breaks least privilege.

Define common permissions once as a ClusterRole and bind them per namespace with RoleBindings to keep each grant inside its namespace.

• ABase64-encode the password a second time before it is stored in the Secret

  Incorrect

  Base64 is an encoding that anyone can reverse; doing it twice protects nothing.

• BMove the password into a ConfigMap and mark that ConfigMap immutable

  Incorrect

  Immutable stops changes, not reading, and ConfigMaps are meant for non-confidential data.

• CChange the Secret's type to Opaque so its data is handled as opaque bytes

  Incorrect

  The type describes the Secret's structure; Opaque Secrets are stored the same way as any other type.

• DEnable encryption at rest for Secrets and restrict Secret reads with RBAC

  Correct

  Secrets are stored unencrypted in etcd by default and their values are only base64 encoded. Encryption at rest protects the stored data; RBAC limits API access.

Base64 is not encryption. Protecting Secrets means encrypting them at rest in etcd and granting read access to Secrets sparingly.

• ALabel the namespace pod-security.kubernetes.io/enforce=restricted

  Correct

  The built-in Pod Security admission controller reads this label and rejects Pods that violate the Restricted profile.

• BLabel the namespace pod-security.kubernetes.io/warn=restricted

  Incorrect

  warn mode shows the user a warning for violations but still allows the Pod.

• CCreate a PodSecurityPolicy that mirrors the Restricted profile's rules

  Incorrect

  PodSecurityPolicy was removed from Kubernetes in v1.25; Pod Security Admission replaced it.

• DApply a default-deny NetworkPolicy in the namespace

  Incorrect

  NetworkPolicy controls traffic between Pods; it does not judge a Pod's security settings.

Pod Security Admission applies the Pod Security Standards per namespace through labels; enforce mode rejects violating Pods, while audit and warn only report them.

• AA Role in kube-system for nodes with a RoleBinding

  Incorrect

  Roles are namespaced, and Nodes are not in any namespace.

• BA ClusterRole for nodes with a RoleBinding in default

  Incorrect

  Nodes are not in any namespace, so a namespaced binding cannot reach them.

• CA ClusterRole for nodes with a ClusterRoleBinding

  Correct

  Nodes are cluster-scoped, so the permission is defined in a ClusterRole and granted with a ClusterRoleBinding.

• DA Role for nodes in each of the namespaces

  Incorrect

  Namespaced Roles cannot cover cluster-scoped resources such as Nodes.

Cluster-scoped resources like Nodes need cluster-wide RBAC objects.

• APrivileged

  Incorrect

  Privileged is unrestricted and allows known privilege escalations.

• BRestricted

  Incorrect

  Restricted is heavily restricted and follows hardening best practices, so more workloads need changes.

• CBaseline

  Correct

  Baseline is minimally restrictive, prevents known privilege escalations and allows the default Pod configuration.

• DDefault

  Incorrect

  Default is not one of the Pod Security Standards.

The three standards are Privileged, Baseline and Restricted, from open to strict.

• AThe default ServiceAccount cannot be bound to a Role

  Incorrect

  The default ServiceAccount can be bound like any other; that is the danger.

• BThe default ServiceAccount is reserved for control plane components

  Incorrect

  Every namespace's Pods use it unless told otherwise.

• CThe default ServiceAccount is deleted when a Pod restarts

  Incorrect

  It exists for the life of the namespace.

• DPods that name no ServiceAccount get default, and its rights

  Correct

  Kubernetes assigns the default ServiceAccount to Pods that name none, so permissions on it reach all of them.

Give each workload its own ServiceAccount with only the permissions it needs, instead of widening the default one.

• Aimpersonate

  Correct

  The impersonate verb lets users impersonate and gain the rights of other users in the cluster.

• Bwatch

  Incorrect

  watch streams changes to resources the user may already read.

• Cpatch

  Incorrect

  patch modifies objects the user is allowed to change; it does not borrow another identity.

• Ddeletecollection

  Incorrect

  This deletes many objects at once but keeps the user's own identity.

RBAC good practices flag impersonate, escalate and bind as verbs that can lead to privilege escalation.