Kubernetes Security Features Questions and Answers for Viva

Answer-1: Kubernetes security refers to securing the infrastructure, workloads, and configurations running within a Kubernetes cluster.

Answer-2: Role-Based Access Control (RBAC) is a method of regulating access to Kubernetes resources based on user roles.

Answer-3: Kubernetes uses certificates, bearer tokens, or external authentication providers (like OIDC) for authentication.

Answer-4: A service account is an identity for processes running in a Pod that allows access to the Kubernetes API.

Answer-5: Secrets store sensitive information, like passwords and tokens, encrypted and separate from application code.

Answer-6: Secrets are base64-encoded and can be encrypted at rest using KMS or envelope encryption.

Answer-7: It enforces predefined security profiles on Pods (restricted, baseline, privileged) to harden workloads.

Answer-8: PSPs are deprecated mechanisms that define security conditions a Pod must meet to be admitted into the cluster.

Answer-9: Network policies control the traffic between Pods and namespaces, acting like firewalls.

Answer-10: A NetworkPolicy defines rules for how groups of Pods can communicate with each other and other network endpoints.

Answer-11: Use the `securityContext` field in Pod specs to limit or drop Linux capabilities.

Answer-12: A security context defines privilege and access control settings for a Pod or container.

Answer-13: Yes, by setting `runAsUser` and `runAsNonRoot` in the Pod?s security context.

Answer-14: mTLS ensures encrypted communication and identity verification between Kubernetes services.

Answer-15: Istio adds mTLS, policy enforcement, and observability to Kubernetes for secure service-to-service communication.

Answer-16: Audit logs track access and changes to the Kubernetes API, useful for security auditing.

Answer-17: Configure the API server with audit policy and log file destination parameters.

Answer-18: etcd is the key-value store used by Kubernetes to store cluster state and configurations.

Answer-19: Use TLS encryption, authentication, firewalling, and restrict direct access to etcd.

Answer-20: Admission Controllers intercept and validate or mutate API requests before persisting them in etcd.

Answer-21: Examples include `NamespaceLifecycle`, `SecurityContextDeny`, and `PodSecurity`.

Answer-22: Use securityContext, seccomp, AppArmor, SELinux, and run containers with least privilege.

Answer-23: Seccomp (Secure Computing Mode) filters system calls and restricts what a container can do on the host.

Answer-24: AppArmor is a Linux kernel security module that restricts program capabilities using profiles.

Answer-25: SELinux is a security module that provides mandatory access controls for processes and files.

Answer-26: Volumes provide persistent storage for Pods, and securing them ensures data is protected.

Answer-27: Use encryption at rest, access control policies, and storage class-level configurations.

Answer-28: It segments cluster resources, network traffic, and permissions to reduce the blast radius of a breach.

Answer-29: Labels help organize and select resources; annotations store non-identifying metadata.

Answer-30: Running unverified images can lead to malware injection or vulnerabilities inside containers.

Answer-31: Use trusted registries, image signing, and vulnerability scanners like Trivy or Clair.

Answer-32: It limits how many Pods can be taken down during voluntary disruptions, useful for availability rather than security.

Answer-33: A DaemonSet ensures that a copy of a Pod runs on all (or some) nodes, useful for security agents.

Answer-34: Tools like Falco and AppArmor monitor live activity for suspicious behavior in containers.

Answer-35: Falco is a CNCF project that detects unexpected behavior in containerized workloads using runtime rules.

Answer-36: It is the front-end for the Kubernetes control plane and must be secured with authentication and authorization.

Answer-37: Kubelet security refers to protecting the agent on each node responsible for running Pods.

Answer-38: Use authentication, authorization, TLS encryption, and disable anonymous access.

Answer-39: ClusterRole applies to all namespaces; Role is limited to one namespace.

Answer-40: Pod Security Admission (PSA) is the new built-in mechanism for enforcing Pod security standards.

Answer-41: Use Kubernetes Certificate Signing Requests (CSRs), cert-manager, or external CAs.

Answer-42: Cert-manager is a Kubernetes add-on that automates management and issuance of TLS certificates.

Answer-43: Use security scanners like kube-bench, kube-hunter, and configuration validators.

Answer-44: Kube-bench checks whether Kubernetes is deployed securely by running CIS benchmark tests.

Answer-45: Kube-hunter probes Kubernetes clusters for security issues to help identify vulnerabilities.

Answer-46: Use RBAC, authentication plugins, API server flags, and audit logging.

Answer-47: It prevents privilege escalation, container breakout, and protects cluster integrity.

Answer-48: Use namespaces, network policies, RBAC, and limit resource access per team or app.

Answer-49: Use image scanning, enforce security policies, and integrate with admission controllers.

Answer-50: Use RBAC, scan images, limit privileges, enable audit logs, and use network policies.