Skip to content

Instantly share code, notes, and snippets.

@cooliscool

cooliscool/gist:85d45bbd0bf4ac50a3ed8108fbff6534

Last active December 1, 2023 01:48
Show Gist options
  • Save cooliscool/85d45bbd0bf4ac50a3ed8108fbff6534 to your computer and use it in GitHub Desktop.
Save cooliscool/85d45bbd0bf4ac50a3ed8108fbff6534 to your computer and use it in GitHub Desktop.
Download ZIP
Kubernetes Policy Engines
Raw
gistfile1.md

Kubernetes Policy Engines: How to Implement Security, Compliance, and Governance Policies in Your Cluster

kubernetes_captain_retouched (image generated by DALL-E)

Embarking on the journey of Kubernetes security unveils a vast landscape, encompassing crucial elements that safeguard your containerized applications. Among the intriguing facets within this realm, we delve into pivotal sections that form the bedrock of Kubernetes security:

  • RBAC Mastery: Kubernetes security begins with defining who holds the keys to the kingdom. Role-Based Access Control (RBAC) empowers you to orchestrate who wields authority over kubectl, the gateway to your Kubernetes cluster. Craft roles and permissions tailored for distinct users and groups, ensuring a finely tuned control mechanism.

  • Secrets Safeguard: The cloak of security extends to shielding your application's secrets. In the digital realm, secrets are akin to treasures — passwords, API keys, and sensitive data. Kubernetes provides a secure vault where these secrets can be stored and utilized, ensuring confidentiality and fortifying your applications against prying eyes.

  • Pods under the Security Lens: As the elemental building blocks of your applications, pods demand a security standard. Enter Pod Security Policies — a set of rules dictating how to fortify your pods. When creating or updating pods, these policies act as sentinels, scrutinizing and enforcing security measures to fortify the very heart of your Kubernetes deployments.

  • Navigating the Network Terrain: In the interconnected Kubernetes ecosystem, Network Policies emerge as the navigational compass. Govern how your pods communicate, both internally and externally, with precision. Through meticulous rule-setting based on labels, ports, and protocols, Network Policies allow you to shape the traffic flow, ensuring a secure and controlled network environment.

Stay with us as we embark on a deep dive into the dynamic realm of Policy Control in Kubernetes. Uncover the nuances, strategies, and best practices that define the security tapestry of your containerized infrastructure.

Policy Control in Kubernetes

Policy Admission Control stands as a formidable mechanism within Kubernetes, ensuring that user-created or updated pods strictly adhere to the pod security standards meticulously set by cluster administrators. This enforcement is made possible through the implementation of admission controllers—plugins that intercept requests to the Kubernetes API server, with the ability to modify or reject them based on specified criteria. The overarching goal of Policy Admission Control is to instill and enforce consistent security policies across the cluster, thwarting the creation of pods that could potentially compromise the security or stability of the entire system.

Built-in Pod Security Admission Controller

At the core of Kubernetes security, the built-in Pod Security Admission Controller emerges as a feature designed to enforce Pod Security Standards within your cluster. These standards encompass predefined security policies that address critical aspects of pod security, including privileges, capabilities, volumes, and network policies.

Enforcing Security Policies

To demonstrate the enforcement of a specific policy, consider the following example command. The command utilizes kubectl to label all namespaces, ensuring adherence to the restricted policy:

kubectl label --dry-run=server --overwrite ns --all \
pod-security.kubernetes.io/enforce=restricted

Native Policy Admission Control vs. 3rd Party

Kubernetes boasts a native feature for governing the admission of pods and services into a namespace based on three fundamental policies: privileged, baseline, and restricted. These policies meticulously define the security and isolation levels for resources within a namespace. However, for those seeking more granular control over pod-level policies, the integration of third-party policy engines with Kubernetes becomes a compelling option. Among the notable third-party policy engines listed on the kubernetes.io website are:

  • Kubewarden
  • Kyverno
  • OPA Gatekeeper

These 'Dynamic' Policy Admins, as exemplified by the aforementioned engines, share common features including validation, mutation, and generation for the enforcement of policies. Key Features of Dynamic Policy Admins are the following:

  • Validation Policies - Ensure cluster resources comply with defined rules, enforcing security best practices, resource quotas, and naming conventions. Validation policies can deny or warn about non-compliant resource creation or modification.
  • Mutation Policies - Modify cluster resources to meet the desired state, injecting labels, annotations, sidecars, or default values. Mutation policies enable alterations, including patching existing resources or applying strategic merge patches.
  • Generation Policies - Creatively craft new cluster resources from existing ones. Automatically generate ConfigMaps, Secrets, or NetworkPolicies for pods and services. Generation policies facilitate resource cloning, synchronization across namespaces, and streamlined resource management for consistency.

How they work - Architecture

The implementation of the pod security admission controller is versatile, available as either a built-in admission plugin or a webhook. In Kubernetes 1.25 and beyond, the built-in plugin is automatically enabled and can be configured using the PodSecurity admission API. Alternatively, the webhook option, an external service, implements the admission webhook API and can be deployed using the pod-security-admission project, offering flexibility and compatibility with older Kubernetes versions.

For third-party engines like 'Kyverno,' the process involves receiving validating and mutating admission webhook HTTP callbacks from the Kubernetes API server. These engines apply corresponding policies, yielding results that enforce admission policies or reject requests.

image

Kyverno in Action - No-Code Kubernetes Policy

Let's take an example of creating a Kyverno policy designed to block or deny any 'exec' requests within a namespace named 'sensitive'. By applying this policy to the Kubernetes cluster, users can seamlessly enforce security measures without the need for manual code, showcasing Kyverno's capabilities for effortless Kubernetes policy management. The policy will look like the following :

kubectl create -f- << EOF
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: deny-exec-in-sensitive-namespace
  annotations:
    policies.kyverno.io/title: Block Pod Exec in Sensitive Namespace
    policies.kyverno.io/category: Sample
    policies.kyverno.io/minversion: 1.6.0
    policies.kyverno.io/subject: Pod
    policies.kyverno.io/description: >-
      The `exec` command may be used to gain shell access, or run other commands, in a Pod's container. While this can
      be useful for troubleshooting purposes, it could represent an attack vector and is discouraged to use in the
      `sensitive` namespace. This policy blocks Pod exec commands to Pods in a Namespace called `sensitive`.
spec:
  validationFailureAction: enforce
  background: false
  rules:
  - name: deny-exec-ns-sensitive
    match:
      any:
      - resources:
          kinds:
          - PodExecOptions
    preconditions:
      all:
      - key: "{{ request.operation || 'BACKGROUND' }}"
        operator: Equals
        value: CONNECT
    validate:
      message: Pods in vault namespace should not be exec'd into
      deny:
        conditions:
          any:
          - key: "{{ request.namespace }}"
            operator: Equals
            value: sensitive
EOF

Let's break down the above policy.

Metadata:
  • Name: deny-exec-in-sensitive-namespace
  • Annotations:
    • policies.kyverno.io/title: Block Pod Exec in Sensitive Namespace
    • policies.kyverno.io/category: Sample
    • policies.kyverno.io/minversion: 1.6.0
    • policies.kyverno.io/subject: Pod
Rules:
  • Rule Name: deny-exec-ns-sensitive
  • Match Condition:
    • Applies to any resource of kind PodExecOptions
  • Preconditions:
    • Triggers only when the request operation (such as CONNECT) matches
  • Validation Action:
    • If conditions are met:
      • Message: "Pods in vault namespace should not be exec'd into"
      • Deny Action: Prevents execution into Pods within the sensitive namespace
Other Settings:
  • validationFailureAction: Enforces the policy
  • background: Set to false, meaning the policy is not applied in the background

In summary, this Kyverno policy ensures that the exec command is disallowed within Pods in the sensitive namespace, mitigating potential security risks. If any attempt is made to execute commands in such Pods, the policy will block it.

Closing Remarks

While Kubernetes excels at managing containerized applications across nodes, ensuring the security and governance of cluster resources demands the implementation and enforcement of policies.

We have seen that third-party admission controllers, external components with enhanced capabilities, extend Kubernetes' policy framework, providing added flexibility and functionality.

In a hands-on example, we've explored how Kyverno, a powerful third-party policy engine, facilitates a no-code policy implementation. This approach simplifies policy creation, offering a practical solution for enforcing desired states and behaviors within your Kubernetes cluster.

References :

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment