Kubernetes 1.30 marks a significant milestone in the evolution of the widely used orchestration platform, particularly regarding security enhancements and developer experience. 

This post will explore updates encompassing secrets management, node and cluster management, data security and additional security measures. Each of these improvements strengthens the Kubernetes framework, making it a more secure and reliable platform for enterprises and developers.

Security-Specific Improvements in Kubernetes 1.30

The Kubernetes 1.30 release brings several enhancements that focus on enhancing the security of sensitive data and bolstering the overall security posture of Kubernetes clusters. 

Enhanced Secrets Management

The new Kubernetes release addresses many Kubernetes Enhancement Proposals (KEPs) that strengthen the security and management of sensitive data in Kubernetes.

#2535: Improved Handling of Secret Images in Container Runtime (Alpha)

KEP #2535 aims to enhance the security of sensitive data by enforcing stricter access controls on images after they have been pulled to a node.

The primary goal is to ensure secure image access with the IfNotPresent image pull policy. The proposal includes changes in the kubelet’s image pull and access mechanisms to enforce proper access to images, particularly those pulled with secret credentials. 

The following example defines a pod with an imagePullPolicy of IfNotPresent and an imagePullSecret. With the enhancement, the kubelet ensures that pods attempting to access the image are authenticated if they do not have the same imagePullSecret:

apiVersion: v1
kind: Pod
metadata:
  name: secret-image-pod
spec:
  containers:
  - name: container
    image: my-private-image
    imagePullPolicy: IfNotPresent
  imagePullSecrets:
  - name: my-registry-key

This enhancement significantly strengthens Kubernetes’ defense against unauthorized access and potential security breaches by implementing stricter controls on already-pulled images.

#2799: Reduction of Secret-Based Service Account Tokens (Stable)

KEP #2799 seeks to reduce the surface area of secret-based service account tokens, which are less secure than bound tokens. This involves changes in the service account control loop in the token controller to stop auto-creating secrets for service accounts. It also includes purging unused auto-generated secret-based service account tokens.

When you create a new service account, the token and its secret will not be generated automatically:

$ kubectl create sa token-test
serviceaccount/token-test created

$ kubectl get sa test-sa -o yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: token-test
  namespace: default

$ kubectl get secrets
No resources found in default namespace.

By reducing the reliance on secret-based service account tokens, Kubernetes is moving towards more secure and simple handling of access credentials. This is particularly important for large-scale and security-sensitive deployments, where managing service account tokens can be challenging.

#4193: Bound Service Account Token Improvements (Beta)

KEP #4193 in Kubernetes 1.30 focuses on enhancing bound service account tokens, providing more robust and secure service account management. The improvement aims to improve the security and usability of bound service account tokens, which are tied to specific pods and are more secure than traditional, non-bound tokens. The KEP proposes several changes, including adding a JWT ID (JTI) and node reference in issued service account tokens to make the tokens more traceable and secure.

By binding tokens to specific pods and adding additional identifiers like JWT IDs, Kubernetes makes it harder for malicious actors to exploit these tokens. This is a key update for organizations that rely on Kubernetes for critical applications, as it provides an additional layer of security for service account management.

Node and Cluster Management

This section reviews major updates on node and cluster management, emphasizing new features that streamline administration and bolster security measures.

#2258: Node Log Query (Beta)

KEP #2258 introduces the node log query feature in Kubernetes 1.30, adding a kubelet API for viewing system service logs on nodes. This simplifies cluster administration and enhances security by allowing data access without additional system access. 

The general usage of the new feature can be illustrated as follows:

kubectl get --raw "/api/v1/nodes/worker/proxy/logs/?query=kubelet&pattern=error"

In this example, the command retrieves logs from the kubelet service running on the worker node with an error in their log line. This simplifies log retrieval, which previously required SSH access to the node.

#3488: CEL for Admission Control (Beta)

KEP #3488 implements the Common Expression Language (CEL) for admission control, allowing for more dynamic and expressive policies in Kubernetes admission controllers. This involves integrating CEL as a language for writing admission control policies, enabling more complex and nuanced rules than possible with the existing admission controllers.

In the following example, a validating admission policy is defined with a CEL expression to validate admission requests:

apiVersion: admissionregistration.k8s.io/v1alpha1
kind: ValidatingAdmissionPolicy
metadata:
  name: "replica-limit-policy.armosec.io"
spec:
  matchConstraints:
    resourceRules:
    - apiGroups:   ["apps"]
      apiVersions: ["v1"]
      operations:  ["CREATE", "UPDATE"]
      resources:   ["deployments"]
  validations:
    - expression: "object.spec.replicas <= 10"

The introduction of CEL for admission control enables administrators to define more complex and tailored policies, improving the overall security posture of Kubernetes clusters. This is significant for organizations with complex security requirements, as it allows them to create finely tuned policies that precisely match the security needs of different applications and environments.
The Kubescape community has already created a library of admission policies in CEL. Feel free to use them for an easy trial of this beta functionality.

#3716: CEL-Based Admission Webhook Match Conditions (Stable)

KEP #3716 aims to introduce CEL expression filters as a stable feature to webhooks, allowing webhooks to be scoped more narrowly and precisely.

For example, with CEL match conditions, you can define complex match rules to exclude lease resources under the coordination.k8s.io group:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
...
rules:
  - operations:
    - CREATE
    - UPDATE
    apiGroups: '*'
    apiVersions: '*'
    resources: '*'
matchConditions:
  - name: 'exclude-leases'
    expression: '!(request.resource.group == "coordination.k8s.io" && resource.resource == "leases")'

KEP #3716 lets administrators define more fine grained  and tailored policies. As with the previous update, this is particularly important for companies that need customized policies for unique security requirements.

Data Security Enhancements

This section covers Kubernetes 1.30 updates that safeguard data integrity and enhance compliance within Kubernetes volumes.

#3141: Prevent Unauthorized Volume Mode Conversion During Volume Restore (Stable)

This enhancement aims to prevent unauthorized volume mode conversion during the restoration of a volume from a snapshot. This involves changes in the Container Storage Interface (CSI) and Kubernetes storage components to ensure that volume mode conversion is explicitly authorized and controlled.

In the following example, a PersistentVolumeClaim (PVC) is defined from a VolumeSnapshot. It includes an annotation that requires explicit authorization to perform volume mode conversion:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  dataSource:
    name: my-volume-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
    snapshot.storage.kubernetes.io/allow-volume-mode-change: "true"

The introduction of this feature boosts the security of data in Kubernetes volumes by requiring authorization for this sensitive activity. This is crucial for environments where data security and integrity are critical, providing additional protection against unauthorized data manipulation.

#1710: Speed Up Recursive SELinux Label Change (Beta)

This Kubernetes 1.30 update focuses on speeding up the container startup time by optimizing the SELinux label change process. The improvement seeks to mount volumes using the appropriate SELinux label, rather than recursively modifying the SELinux label of each file within the volumes. 

For the following pod definition, the mounted volume, volume-1, will be labeled with the specific SELinux label at mount time, resulting in a faster container startup process:

apiVersion: v1
kind: Pod
...
    volumeMounts:
    - name: volume-1
      mountPath: /data
  securityContext:
    seLinuxOptions:
      level: "s0:c123,c456"
  volumes:
  - name: volume-1
    persistentVolumeClaim:
      claimName: pvc-1

The optimization of the SELinux label change process significantly enhances the startup time of containers in Kubernetes, especially in environments with a large number of files in volumes.

#127: Support for User Namespaces in Pods (Beta)

KEP #127 introduces support for user namespaces in pods. It enhances pod isolation to mitigate high/critical CVEs, and supports custom UID/GID ranges. This involves changes to provide a way to remap UIDs and GIDs in a pod to different values in the host system.

The following example defines a pod that does not use host users, which is explicitly mentioned in the spec:

apiVersion: v1
kind: Pod
metadata:
  name: ns-test
spec:
  hostUsers: false
  containers:
  - name: sleep
    command: ["sleep", "infinity"]
    image: debian

Introducing user namespaces in pods greatly improves the security and isolation of workloads in Kubernetes, by bringing this valuable functionality to the pod level. This is important for environments that require strict security and isolation between pods, as it provides a more robust mechanism to prevent privilege escalation and other security threats.

Additional Security Measures

Kubernetes 1.30 brings a slew of additional new features and updates that further enhance the platform’s security landscape, from container isolation to authorization controls.

#4191: Kubelet Support for Image Filesystem Split (Alpha)

KEP #4191 separates between the writable and read-only layers of the container’s filesystem.This provides more robust isolation, reducing the risk of unauthorized modifications to the filesystem. Which is particularly important for environments where container security is a top priority, as it provides additional protection against potential security threats.

#24: AppArmor Support (Stable)

KEP #24 adds support for AppArmor profiles, which offer a powerful mechanism for defining and enforcing security policies at the container level. This involves integrating AppArmor support into Kubernetes, enabling the use of AppArmor profiles and adding a layer of protection against various types of security threats. 

Profiles can be specified in pod annotations as follows:

apiVersion: v1
kind: Pod
metadata:
  name: apparmor
  annotations:
    container.apparmor.security.beta.kubernetes.io/hello: localhost/k8s-apparmor-deny-write
...

This enhancement is significant for environments that require stringent security measures, as it allows administrators to define custom security policies tailored to the specific needs of their applications.

#3221: Structured Authorization Configuration (Beta)

This update introduces structured authorization configuration, allowing for more granular and customizable authorization controls in Kubernetes, including the use of multiple authorization webhooks.

The following example shows how to protect resources in kube-system namespaces with AuthorizationConfig:

apiVersion: apiserver.config.k8s.io/v1alpha1
kind: AuthorizationConfiguration
authorizers:
  - type: Webhook
    name: system-crd-protector
      matchConditions:
      ... 
       - expression: request.resourceAttributes.namespace == 'kube-system'
       - expression: request.resourceAttributes.verb in ['update', 'delete','deletecollection']
     ...

The introduction of structured authorization configuration lets administrators define more fine-grained and tailored policies. This improves the overall security posture of Kubernetes clusters and is particularly important for organizations with complex security requirements.

Removal of SecurityContextDeny Admission Plugin

In Kubernetes 1.30, the SecurityContextDeny admission plugin, which has been deprecated since version 1.27, is officially removed. This plugin previously denied pod creation requests that defined specific security context settings. Its removal marks a noteworthy shift towards more modern and flexible security practices in Kubernetes. As a recommended replacement, Kubernetes now advocates using the PodSecurity admission plugin, which offers a more comprehensive and nuanced approach to managing security contexts in pods. 

General Enhancements in Kubernetes 1.30

In this section, we shift the spotlight to developer-focused improvements in Kubernetes 1.30, which streamline development processes and reinforce the overall security framework.

#4402: Go Workspaces for Kubernetes (Stable)

KEP #4402 introduces the use of Go multi-module workspaces for Kubernetes. Thus, simplifying the management of multiple Go modules and enhancing the developer experience. You can learn more about using workspaces in Go via its official tutorial and start using the go.work file, which is part of the main Kubernetes repository.
Shout out to Tim Hockin for pushing this through over 18 months.

#3960: Introducing Sleep Action for PreStop Hook (Beta)

Kubernetes now has sleep action for the preStop hook, enhancing the control over pod termination processes. In the following deployment spec, when a pod delete event is sent, the preStop hook will delay the shutdown by 5 seconds:

apiVersion: apps/v1
kind: Deployment
...
    spec:
      containers:
      - name: nginx
        image: nginx:1.16.1
        lifecycle:
          preStop:
            sleep:
              seconds: 5
...

This feature allows for a more graceful shutdown of pods, and is particularly important in scenarios where immediate termination could lead to data corruption or incomplete transactions.

#1610: Container Resource-Based Pod Autoscaling (Stable)

KEP #1610 introduces container resource-based pod autoscaling, which allows for more dynamic and efficient application scaling. This involves extending the HorizontalPodAutoscaler (HPA) to support scaling according to the consumption of containers within a pod rather than just the pod-level metrics.

In the following example, an HPA is defined to scale a deployment based on the CPU utilization of individual containers. The HPA will adjust the number of replicas to maintain an average CPU utilization of 50% across all containers:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-hpa
spec:
  ...
  metrics:
  - type: ContainerResource
    containerResource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

This functionality is particularly beneficial for complex applications with varying resource demands across their containers. It allows for tailored scaling strategies that can improve resource utilization and application performance.

#4381: DRA: Structured Parameters (Alpha)

This update aims to improve dynamic resource allocation (DRA) using structured parameters. This enables the kube-scheduler and Cluster Autoscaler to manage and simulate the allocation of claims independently, without the need for a third-party driver. The #4381 enhancement provides a more robust mechanism for managing resources in Kubernetes. Which is particularly beneficial for complex applications and environments that require fine-grained control over resource allocation. This change is abstracted away from the end-user with no modification required in the pod spec and it results in more efficient scheduling.

Conclusion

Kubernetes 1.30 brings enhancements that collectively improve the security, scalability, and developer experience within Kubernetes environments. Here’s a summary of the key takeaways:

• Enhanced secrets management: Improvements in handling secret images and service account tokens bolster the security of sensitive data and reduce potential attack surfaces.
• Improved node and cluster management: The introduction of node log query and CEL for admission control enhances the ease of administration and the flexibility of security policy enforcement.
• Data security enhancements: Features like preventing unauthorized volume mode conversion and improving the SELinux relabeling process safeguard data security within Kubernetes volumes.

Overall, Kubernetes 1.30 reflects the community’s commitment to advancing the platform’s capabilities regarding security and developer experience. To access further details and updates, visit the Kubernetes changelog on GitHub or follow Kubernetes’ own blog.

Actionable, contextual, end-to-end
{Kubernetes-native security}

From code to cluster, helm to node, we’ve got your Kubernetes covered:

Cut the CVE noise by significantly reducing CVE-related work by over 90%

Automatic Kubernetes compliance for CIS, NSA, Mitre, SOC2, PCI, and more

Manage Kubernetes role-based-access control (RBAC) visually

The post Kubernetes 1.30: A Security Perspective appeared first on ARMO.

*** This is a Security Bloggers Network syndicated blog from ARMO authored by Ben Hirschberg. Read the original post at: https://www.armosec.io/blog/kubernetes-1-30-security/