Kubernetes v1.31 brings about some noteworthy improvements to the popular container orchestration platform that improve security and other aspects within the platform.

These enhancements improve account tokens, labeling, policies, and other areas to ensure a more secure and reliable platform for developers and enterprises.

Security-specific improvements in Kubernetes 1.31

The Kubernetes v1.31 introduces several security-related improvements that improve the overall security posture of the platforms and the workloads.

#24 AppArmor support

The AppArmor support enhancement (KEP-24) integrate AppArmor into Kubernetes, providing a way to enforce mandatory access control (MAC) policies for pods and containers.

AppArmor is a Linux security module that restricts programs’ capabilities through profiles, reducing the risk of security breaches. By allowing users to specify AppArmor profiles in Kubernetes manifests, this enhancement helps isolate and protect workloads, ensuring that even if an application is compromised, its ability to cause harm is limited by predefined security policies.

Key Aspects:

1. Profile specification: Users can define AppArmor profiles in pod manifests.
2. Profile enforcement: The specified profiles are enforced at runtime, restricting the capabilities of containers.
3. Isolation: Enhances isolation between workloads, reducing the attack surface.
4. Security: Helps mitigate potential damage from compromised applications by limiting their actions.

Benefits:

1. Enhanced security: By restricting what applications can do, even if compromised.
2. Granular control: Provides fine-grained control over container permissions.
3. Compliance: Helps meet security compliance requirements by enforcing strict access controls.

Implementation details:

1. Annotations: AppArmor profiles are specified using annotations in pod definitions.
2. Profile management: Administrators need to manage and maintain AppArmor profiles on the nodes.

Compatibility: Requires underlying node support for AppArmor.

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    container.apparmor.security.beta.kubernetes.io/container-name: localhost/profile-name
spec:
  containers:
  - name: container-name
    image: sample-image

For more detailed information, please visit the KEP-24 issue page.

#2535 Ensure Secret Pulled Images

This Kubernetes enhancement enhances the security of pulling container images that require secrets, such as private registry credentials. The key goal is to ensure these secrets are securely managed and used during the image-pulling process, mitigating risks associated with unauthorized access to sensitive data.

Key aspects:

1. Secure secret management: Ensures secrets used in image pulls are managed securely.
2. Access control: Implements access controls to prevent unauthorized access to these secrets.
3. Auditing and logging: Enhances auditing and logging to track secret usage and access.

Benefits:

1. Improved security: Reduces the risk of unauthorized access to private images.
2. Compliance: Helps meet security and compliance requirements by securely handling secrets.
3. Visibility: Provides better visibility into secret usage and potential security issues.

Implementation details:

1. Kubelet enhancements: Modifies Kubelet to securely handle secrets during image pulls.
2. Secret distribution: Ensures secrets are distributed securely to nodes and used appropriately.
3. Configuration: Administrators can configure policies to manage how secrets are handled during image pulls.

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: private-registry.example.com/my-image
    imagePullSecrets:
    - name: my-registry-secret

For more detailed information, please visit the KEP-2535 issue page.

#4633 Only Allow Anonymous Auth For Configured Endpoints

This Kubernetes enhancement improves security by restricting anonymous authentication to only specific, pre-configured endpoints. It aims to reduce the risk associated with unrestricted anonymous access, which could be exploited by malicious users.

Key Aspects:

1. Controlled access: Limits anonymous access to specific, safe endpoints only.
2. Configuration: Administrators can define which endpoints allow anonymous access.
3. Security: Enhances overall cluster security by minimizing the potential attack surface.

Benefits:

1. Enhanced security: Reduces unauthorized access risks.
2. Compliance: Helps in meeting security compliance requirements.
3. Granular control: Provides fine-grained control over endpoint access.

Implementation details:

1. API server configuration: Changes in the API server to support this functionality.
2. Endpoint management: Administrators specify endpoints in configuration files.

For more detailed information, please visit the KEP-4193 issue page.

#4193 Bound Service Account Token Improvements

This enhancement aims to improve the security and usability of bound service account tokens in Kubernetes. These tokens are used to authenticate pods to the Kubernetes API server and other services. The goal is to enhance their lifecycle management, rotation, and revocation, addressing security issues associated with long-lived tokens.

Key Aspects:

1. Token bound to pods: Tokens are closely tied to the pod’s lifecycle, ensuring they are valid only as long as the pod exists.
2. Automatic rotation: Tokens are automatically rotated, reducing the risk of misuse if a token is compromised.
3. Revocation: Enhances the ability to revoke tokens when they are no longer needed.

Benefits:

1. Improved security: Reduces risks associated with long-lived and stale tokens.
2. Ease of use: Simplifies token management for developers and operators.
3. Compliance: Helps meet security compliance requirements by ensuring robust token management.

Implementation details:

1. TokenRequest API: Introduces a new API to request tokens that are bound to the pod’s lifecycle.
2. Shorter token lifetimes: Configures tokens to have shorter lifetimes, with automatic renewal mechanisms.
3. Revocation mechanisms: Provides mechanisms to revoke tokens when they are no longer needed or when the pod is terminated.

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  serviceAccountName: example-service-account
  containers:
  - name: example-container
    image: example-image

For more detailed information, please visit the KEP-4193 documentation.

#3908 kube-apiserver Support Out-of-Process JWT Signing

This enhancement aims to improve the security and flexibility of the Kubernetes API server by supporting out-of-process JSON Web Token (JWT) signing. This allows the API server to delegate the responsibility of signing tokens to an external process or service, enhancing security and scalability.

Key aspects:

1. External JWT signing: Allows the Kubernetes API server to use an external process for signing JWTs.
2. Increased security: Reduces the risk associated with the API server handling private keys directly.
3. Scalability: Enhances scalability by offloading token signing to a specialized service.

Benefits:

1. Enhanced security: Isolates the signing process, reducing the attack surface.
2. Flexibility: Allows integration with external identity providers and signing services.
3. Improved management: Simplifies key management and rotation processes.

Implementation details:

1. Configuration: Administrators configure the API server to delegate JWT signing to an external process.
2. External signing service: The external service must implement a specific API to handle signing requests.

For more detailed information, please visit the KEP-3908 documentation.

4601 Authorize With Field and Label Selectors

This enhancement introduces the ability to use field and label selectors in authorization policies, allowing for more granular access control in Kubernetes. By enabling these selectors, administrators can define precise rules based on resource fields and labels, improving the flexibility and security of the access control system.

Key Aspects:

1. Field selectors: Allows authorization policies to use resource field values.
2. Label selectors: Enables the use of resource labels in access control decisions.
3. Granular access control: Provides finer control over who can access specific resources.

Benefits:

1. Enhanced security: Reduces over-permission by allowing precise access control.
2. Flexibility: Supports complex policies based on resource attributes.
3. Improved management: Simplifies the creation of detailed and specific authorization rules.

Implementation details:

1. Policy definition: Administrators can define policies using field and label selectors.
2. API server changes: Modifications to the API server to support these selectors in authorization checks.

For more details, visit the KEP-4601 documentation.

#3962 Mutating Admission Policies

This enhancement aims to introduce mutating admission policies in Kubernetes, providing a flexible way to modify requests to the API server. These policies are evaluated and applied before the requests are persisted, enabling dynamic modification of resources based on custom criteria.

Key aspects:

1. Dynamic modification: Allows the modification of API requests before they are persisted.
2. Custom policies: Supports custom criteria for modifying requests.
3. Flexibility: Enhances the flexibility of Kubernetes admission control.

Benefits:

1. Enhanced control: Provides fine-grained control over API requests.
2. Customization: Allows administrators to define custom logic for modifying resources.
3. Improved security: Ensures that requests meet specific policies before being accepted.

Implementation details:

1. Policy definition: Administrators define mutating policies using CustomResourceDefinitions (CRDs).
2. Admission webhooks: Utilizes mutating admission webhooks to apply the defined policies.

Mutating admission policies Vs mutating webhooks

Mutating Admission Policies and Mutating Admission Webhooks in Kubernetes both serve the purpose of modifying requests to the API server before they are persisted. However, there are distinct differences in how they operate and their flexibility. The following table shows a comparison between the two.

Conclusion

Kubernetes v1.31 brings several enhancements that significantly improve security, scalability, and developer experience within the platform. Key takeaways include:

1. Enhanced Security Mechanisms: Integrations such as AppArmor support (KEP-24) for mandatory access control, improved management of secret-pulled images (KEP-2535), and restrictions on anonymous authentication (KEP-4633) enhance the security of workloads and data within Kubernetes.
2. Improved Token Management: Enhancements to bound service account tokens (KEP-4193) ensure better lifecycle management, rotation, and revocation, reducing risks associated with long-lived tokens.
3. Advanced Authorization Control: Features like out-of-process JWT signing (KEP-3908) and authorization with selectors (KEP-4601) provide more granular and flexible access control and security measures.
4. Flexible Admission Policies: The introduction of mutating admission policies (KEP-3962) allows for dynamic modification of API requests, enhancing control over resource configurations and security.

These updates underscore Kubernetes’ commitment to advancing its security and usability, making it a more secure and reliable platform for developers and enterprises. For more details, visit the respective KEP issue pages and documentation.

The post Kubernetes 1.31: 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-31-security-perspective/