Kubernetes Security Basics: RBAC u0026 Service Accounts Quiz Quiz

Explore essential Kubernetes security fundamentals with this quiz focused on Role-Based Access Control (RBAC) and Service Accounts. Assess your understanding of permissions, roles, best practices, and practical scenarios for managing secure access in container orchestration environments.

1. Understanding RBAC Roles

   In Kubernetes, which RBAC object would you use to grant read-only access to resources within a specific namespace for a group of users?

   1. ClusterRole
   2. PodSecurityPolicy
   3. RoleBinding
   4. Role

   Explanation: The correct answer is Role, which defines a set of permissions within a specific namespace. RoleBinding links the role to users or groups but does not itself define permissions. ClusterRole operates across all namespaces, which is broader than the scope described. PodSecurityPolicy is unrelated to RBAC roles and instead governs pod-level security controls, not resource access assignments.

2. Service Account Usage in Pods

   When you deploy a new pod in Kubernetes without specifying a service account, what happens by default?

   1. The pod is assigned the default service account in its namespace.
   2. The pod inherits admin privileges from the cluster.
   3. The pod is denied all access to the API server.
   4. The pod fails to start due to missing credentials.

   Explanation: By default, pods are automatically assigned to the default service account present in their namespace. The pod will not fail to start due to missing credentials since the default service account exists by design. Inheriting admin privileges does not occur unless the default service account is configured that way, which is not standard. The pod is not outright denied all API server access; it gets permissions based on the service account's configuration.

3. RoleBinding vs ClusterRoleBinding

   Given a scenario where you need to allow a user to list pods across all namespaces, which RBAC binding should you create?

   1. ClusterRoleBinding to a ClusterRole
   2. RoleBinding to a Role
   3. RoleBinding to a ClusterRole
   4. ClusterRoleBinding to a Role

   Explanation: ClusterRoleBinding to a ClusterRole allows granting permissions that cover all namespaces, suitable for global actions like listing pods throughout the cluster. RoleBinding to a Role limits access to a single namespace, not all. RoleBinding to a ClusterRole only applies the ClusterRole in a specific namespace. ClusterRoleBinding to a Role is invalid as ClusterRoleBinding requires binding to a ClusterRole object.

4. Principle of Least Privilege

   Which practice best aligns with the principle of least privilege when assigning service account permissions in Kubernetes?

   1. Grant only the minimal set of permissions needed for the workload.
   2. Grant permissions to all resources regardless of workload requirements.
   3. Share the default service account among all pods in the namespace.
   4. Assign full cluster administrator privileges to all service accounts.

   Explanation: The correct application of least privilege is assigning the minimal set of permissions required for a given workload. Granting full cluster administrator rights or permissions to all resources exceeds necessary access and poses security risks. Sharing the default service account can inadvertently raise privilege issues if multiple pods have differing needs, making it less secure.

5. Service Account Token Risks

   Why should you avoid mounting unnecessary service account tokens into your Kubernetes pods?

   1. It results in more complex network policies.
   2. It increases the risk of privilege escalation if a token is compromised.
   3. It decreases pod performance noticeably.
   4. It prevents the pods from accessing the Kubernetes API.

   Explanation: Mounting unnecessary tokens gives applications access to credentials they may not need, increasing the attack surface if the token is leaked or stolen. Pod performance is generally not affected by token presence. Network policies do not become inherently more complex due to service account tokens. In fact, mounting a service account token allows, rather than blocks, Kubernetes API access.