In the latest versions of K8s there has been an evolution regarding the definition of security strategies at the level of access policies to the cluster by users and developers. The security contexts (securityContext) allow you to define the configurations at the level of access control and privileges for a pod or container in a simple way using keywords in the configuration files.
To facilitate the implementation of these security strategies throughout the cluster, new strategies have emerged such as the Pod Security Policy (PSP) where the cluster administrator is in charge of defining these policies at the cluster level with the aim that developers can follow these policies.
Other interesting projects include Open Policy Agent (OPA) as the main cloud-native authorization policy agent for creating policies and managing user permissions for access to applications.
The objective of this talk is to present the evolution that has occurred in security strategies and how we could use them together, as well as analyze their behavior in accessing resources. Among the points to be discussed we can highlight:
*Introduction to security strategies in K8s environments
*Pod Security Admission(PSA) vs Open Policy Agent (OPA)
*Combination of different security strategies together
*Access to resources in privileged and non-privileged mode
2. www.containerdays.io
#CDS23
Agenda
● Introduction to security strategies in K8s
environments
● Pod Security Admission(PSA) vs Open Policy Agent
(OPA)
● Combination of different security strategies together
● Access to resources in privileged and non-privileged
mode
3. www.containerdays.io
#CDS23
Introduction to security strategies in K8s environments
● Cluster Hardening: Implement best practices for securing
the Kubernetes cluster itself, including securing access to
the API server, enabling RBAC (Role-Based Access
Control), and using network policies to control
communication between pods.
● Pod Security Policies (PSP): Enforce security policies that
define what a pod can and cannot do, including limiting
privilege levels, host access, and running as non-root users.
4. www.containerdays.io
#CDS23
Introduction to security strategies in K8s environments
● Secrets Management: Use Kubernetes Secrets to
store sensitive information securely, such as API
keys, passwords, or certificates.
● Role-Based Access Control (RBAC): Define
fine-grained access controls for users and service
accounts to limit the scope of actions they can
perform within the cluster.
5. www.containerdays.io
#CDS23
Introduction to security strategies in K8s environments
● Limit Resource Consumption: Set resource quotas
to limit the amount of CPU, memory, and other
resources that can be consumed by pods, preventing
resource exhaustion and potential denial-of-service
attacks.
● Pod Security Context: Use pod security context to
define security settings at the pod level, such as user
and group IDs, SELinux, and file system permissions.
12. www.containerdays.io
#CDS23
● New form of admission control is created with the
understanding that Kubernetes users are probably going
to seek external authorization.
● It can be deactivated partially or entirely to coexist with
external admission controllers like OPA.
● KEP-2579: Pod Security Admission Control
● https://github.com/kubernetes/enhancements/blob/mast
er/keps/sig-auth/2579-psp-replacement/README.md
Pod Security Admission(PSA)
15. www.containerdays.io
#CDS23
Pod Security Admission(PSA)
● Pod Security admission places requirements on a Pod's
Security Context and other related fields according to the
three levels defined by the Pod Security Standards:
privileged, baseline, and restricted.
● spec.containers[*].ports
● spec.volumes[*].hostPath
● spec.securityContext
● spec.containers[*].securityContext
17. www.containerdays.io
#CDS23
Pod Security Admission(PSA)
Mode Description
enforce Policy violations will cause the pod to be
rejected.
audit Policy violations will trigger the addition of an
audit annotation to the event recorded in the
audit log, but are otherwise allowed.
warn Policy violations will trigger a user-facing
warning, but are otherwise allowed.
20. www.containerdays.io
#CDS23
Pod Security Admission(PSA)
● It is consistent in deploying the security levels on
namespaces by labels which helps with testing,
troubleshooting and maintaining.
● Ability to perform dry runs using --dry-run=server
before applying pod-security on namespace labels
● Provides validations for compliance with policies and
will not change the pods to enforce compliance.
24. www.containerdays.io
#CDS23
Pod Security Admission(PSA)
$ kubectl apply -f pod.yaml
Warning: would violate "latest" version of "restricted" PodSecurity profile:
allowPrivilegeEscalation != false (container "nginx" must set
securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container
"nginx" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true
(pod or container "nginx" must set securityContext.runAsNonRoot=true),
seccompProfile (pod or container "nginx" must set
securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
pod/nginx created
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 6s
28. www.containerdays.io
#CDS23
● Policy agent for cloud-native authorization
● It provides a means of standardizing policy definition
and management throughout the cloud-native
technology stack.
● When combined with Kubernetes, OPA has the
capability to enforce guardrails upon an entire
system, requiring users’ permissions to match policy
at all times.
30. www.containerdays.io
#CDS23
● Require specific labels on all resources.
● Require container images from the corporate image
registry.
● Require all Pods specify resource requests and limits.
● Prevent conflicting Ingress objects from being created.
34. www.containerdays.io
#CDS23
Pod Security Admission(PSA) vs Open Policy Agent(OPA)
Pod Security Admission (PSA) Open Policy Agent (OPA)
Simplicity Flexibility
Native Integration Customization
Performance External Control
Limited Attack Surface Compliance
35. www.containerdays.io
#CDS23
Pod Security Admission(PSA) vs Open Policy Agent(OPA)
● Which users can access which resources?
● Which subnets egress traffic is allowed to?
● Which clusters a workload must be deployed to?
● Which registries images can be downloaded from?
● Which capabilities a container can execute with?
● Which times of day the system can be accessed at?