User Namespaces for Improved Pod Isolation [Beta]

This innovative feature, now in beta, provides users within pods with precise control over their identities. It allows mapping different values from the host system to the UIDs (User IDs) and GIDs (Group IDs) utilized inside a pod. This method significantly reduces the attack surface, making it harder for compromised containers to exploit privileges on the host.

apiVersion: v1

kind: Pod

metadata:

name: my-secure-pod

spec:

securityContext:

userNamespace: true

containers:

• name: my-app

  image: my-secure-image:latest

In this example, the Kubelet is directed to execute the container with a dedicated user namespace by setting the userNamespace: true property within the securityContext.

Bound Service Account Tokens [Beta]

Bound service account tokens (SATs) offer a more secure alternative for service account authentication compared to traditional, non-bound tokens. These tokens, introduced as beta in 1.30, are tied to specific pods and grant access only to the resources required by those pods, thereby minimizing the potential impact of compromised tokens.

apiVersion: v1

kind: Pod

metadata:

name: my-pod-with-bound-sat

spec:

serviceAccountName: my-service-account

template:

spec:

securityContext:

# Enables the use of the bound service account token

podSecurityContext: {}

By incorporating the podSecurityContext: {} section, the pod can utilize the bound service account token associated with the specified service account (my-service-account).

Node Log Queries

Understanding node logs is crucial for security assessments and troubleshooting. With the introduction of Node Log Query in Kubernetes 1.30, administrators can now query system service logs on nodes directly via the kubelet API. This capability reduces the attack surface and accelerates log collection without needing extra system access, thereby enhancing security.

For example, you can run the following command to search for kubelet process-related errors in the logs:

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

This command retrieves logs from the kubelet process on the “worker” node that specifically contain the term “error.”

AppArmor Profile Configurations with Pod Security Contexts

AppArmor profiles within containers provide a robust method for enforcing application security policies. Kubernetes 1.30 simplifies AppArmor configuration by allowing administrators to specify profiles directly in the PodSecurityContext and container.securityContext fields. This streamlines policy management, eliminating the need for beta AppArmor annotations.

apiVersion: v1

kind: Pod

metadata:

name: my-pod-with-apparmor

spec:

securityContext:

apparmorProfile: "restricted-runtime"

containers:

• name: my-app

  image: my-app-image:latest

  securityContext:

  apparmorProfile: "runtime/default"

In this setup, the “my-app” container utilizes the “runtime/default” profile, while the pod itself is assigned the “restricted-runtime” profile, providing granular control over AppArmor policies at both the pod and container levels.

Node Memory Swap

Kubernetes 1.30 introduces support for node memory swapping, potentially enhancing system stability under memory pressure by allowing the kernel to utilize swap space on nodes for memory management.

The node memory swap feature has been redesigned to emphasize stability and control. With LimitedSwap replacing UnlimitedSwap, Kubernetes offers a more predictable method for managing swap usage on Linux nodes. Be sure to evaluate your specific needs before enabling swap and implement appropriate monitoring measures.

kind: KubeletConfiguration

apiVersion: kubelet.config.k8s.io/v1beta1

# ... other kubelet configurations

featureGates:

NodeSwap: "true"

memorySwap:

swapBehavior: LimitedSwap

Container Resource-Based Pod Autoscaling

This feature enables horizontal pod autoscaling (HPA) based on container memory or CPU metrics, allowing for more precise scaling according to the actual demands of containers. By focusing on the metrics of individual containers, you can optimize resource allocation and scaling strategies across your Kubernetes clusters.

apiVersion: autoscaling/v2beta2

kind: HorizontalPodAutoscaler

metadata:

name: my-hpa

spec:

scaleTargetRef:

apiVersion: apps/v1

kind: Deployment

name: my-deployment

minReplicas: 2

maxReplicas: 5

metrics:

• type: Resource

  resource:

  name: cpu

  target:

  type: Utilization

  averageUtilization: 80

containerMetrics:

• name: web-container # Target container within the Pod

During deployment, the HPA monitors the CPU resource usage of each pod. It will scale the deployment to maintain an average CPU usage of 80% across all instances of the web container, as specified in the containerMetrics section.

Dynamic Resource Allocation

Structured parameters enhance the flexibility of resource allocation for pods. By precisely defining resource requests and limits, developers can optimize the use of available resources.

In this scenario, the pod requests a minimum and maximum of one GPU resource (nvidia.com/gpu) and also requests 8GB of memory.

apiVersion: v1

kind: Pod

metadata:

name: my-gpu-app

spec:

containers:

• name: gpu-container

  resources:

  requests:

  resource.k8s.io/nvidia.com/gpu:

  type: Resource

  minimum: 1

  maximum: 1

  resource.k8s.io/memory:

  type: Resource

  requests:

  memory: "8Gi"

Dynamic Resource Allocation in Kubernetes 1.30 paves the way for a more dynamic and efficient resource management environment through structured parameters. As this feature evolves, we can expect broader adoption and the emergence of a vibrant ecosystem of third-party resource drivers to meet various application needs.

Imran Roshan

Linkborg imranfosec.linkb.org