Container u0026 Kubernetes Security Basics Quiz Quiz

Explore key principles of container and Kubernetes security with this quiz designed to assess your understanding of best practices, common threats, and critical concepts in secure orchestration environments. Ideal for IT professionals and learners aiming to enhance their knowledge in containerized application security.

1. Container Image Risks

   Which of the following poses the greatest security risk when building container images from public sources in a deployment pipeline?

   1. Labeling the container image with metadata
   2. Using unknown or untrusted base images from public repositories
   3. Exposing only port 80 in the Dockerfile
   4. Setting the image CMD instruction to a shell

   Explanation: Using unknown or untrusted base images from public sources increases the risk of including vulnerabilities or malicious code in your containers. Setting the CMD instruction to a shell is often a deployment choice but does not inherently introduce risk. Exposing only port 80 is merely a configuration for networking and does not directly relate to image integrity. Labeling a container with metadata is a standard practice for organization and does not pose a security threat.

2. Kubernetes Role-Based Access Control

   What is the primary objective of implementing Role-Based Access Control (RBAC) within a Kubernetes cluster?

   1. To encrypt traffic between nodes
   2. To restrict users and services to only the permissions they require
   3. To prevent pods from accessing host storage
   4. To limit resource consumption by pods

   Explanation: RBAC is designed to ensure that users and services possess only the minimum permissions needed to perform their functions, thus reducing the risk of accidental or malicious actions. Limiting resource consumption by pods is managed through resource quotas, not RBAC. Preventing pods from accessing host storage is achieved via security contexts or policies, not RBAC. Encrypting node traffic relates to network security settings rather than access control.

3. Container Isolation Mechanisms

   How does using namespaces enhance security in a containerized environment?

   1. By automatically updating containers with patches
   2. By enforcing strict password requirements for shell access
   3. By sharing filesystems among all containers by default
   4. By isolating resources like process IDs and network stacks for each container

   Explanation: Namespaces ensure that containers only see and interact with their own processes, network interfaces, and other resources, increasing isolation and reducing the impact of breaches. Sharing filesystems is usually restricted, not done by default, as it would weaken isolation. Automatic patching must be implemented separately and is not a function of namespaces. Namespaces do not enforce password requirements; that relates to authentication mechanisms.

4. Kubernetes Secrets Management

   When storing sensitive data such as database credentials in Kubernetes, what is the recommended resource type to use?

   1. ConfigMap
   2. PersistentVolume
   3. Secret
   4. Deployment

   Explanation: Kubernetes Secrets are specifically intended for storing sensitive information like passwords and tokens and provide an additional layer of protection compared to ConfigMaps. ConfigMaps are designed for non-sensitive configuration data and do not offer the same security controls. Deployments are used for managing application replicas and do not store data. PersistentVolumes are for storage, not credentials or secrets.

5. Privileged Containers Risk

   What is the main security concern associated with running containers in privileged mode?

   1. Privileged containers bypass Kubernetes scheduling rules
   2. Network policies will not apply to privileged containers
   3. The container can automatically scale without restrictions
   4. The container could access and modify host resources, increasing potential attack surface

   Explanation: Privileged mode grants the container elevated permissions, allowing it to interact with host resources and potentially compromise the host system. Automatic scaling is unaffected by privilege and is a matter of deployment configuration. Network policies still apply to privileged containers unless otherwise specified. Kubernetes scheduling rules are not bypassed by privileged containers, as privilege only affects the container's capabilities within its environment.