OpenKruise Agents v0.6.0: Elevating Sandbox Security and Automation
OpenKruise Agents v0.6.0 exists to streamline the lifecycle management of agent sandboxes running at scale on Kubernetes. As applications grow, so do the complexities of managing secure and efficient traffic flow. This release tackles these challenges head-on, enhancing both security and automation capabilities for Kubernetes workloads.
At its core, OpenKruise Agents employs a two-stage traffic takeover mechanism. It combines node-side L4 and central L7 processing to balance performance with functionality. The traffic flow starts from the sandbox application container, moves through an in-pod traffic proxy for L4 capture, and then routes through an egress gateway. This setup allows for fine-grained control over outbound requests, enabling features like credential injection and security profiles that can block or bypass specific HTTP requests based on defined rules. For instance, the TrafficPolicy can specify which services are allowed or rejected, while the SecurityProfile can enforce actions like blocking access to internal services.
In production, you need to be aware of the theoretical upper bounds of performance metrics. Monitor the request duration via the gateway logs and watch for 502 errors or packet loss, which can indicate issues in your traffic management. The version 0.6.0 introduces robust features, but understanding the nuances of traffic policies and security profiles is crucial for effective implementation.
Key takeaways
- →Utilize the two-stage traffic takeover for efficient traffic management.
- →Implement TrafficPolicy to control egress rules based on your application needs.
- →Leverage SecurityProfile to enforce security actions on HTTP requests.
- →Inject credentials securely using Kubernetes Secrets for outbound requests.
- →Monitor gateway logs for request duration and potential packet loss.
Why it matters
In real production environments, the ability to manage traffic securely and efficiently can significantly reduce the risk of data leaks and improve application performance. OpenKruise Agents v0.6.0 equips teams with the tools needed to navigate these challenges effectively.
Code examples
1apiVersion: agents.kruise.io/v1alpha1
2kind: TrafficPolicy
3metadata:
4 name: sandbox-egress
5spec:
6 selector:
7 matchLabels:
8 app: traffic-sample
9 egress:
10 rules:
11 - action: allow
12 to:
13 - service: {name: kube-dns, namespace: kube-system}
14 - action: allow
15 to:
16 - fqdn: api.example.com
17 - action: reject
18 ports: [{protocol: TCP, port: 443}]
19 to:
20 - cidr: 10.0.0.0/81apiVersion: agents.kruise.io/v1alpha1
2kind: GlobalSecurityProfile
3metadata:
4 name: cluster-baseline
5spec:
6 selector:
7 matchLabels: {app: traffic-sample}
8 priority: 50 # cluster baseline deliberately ordered before tenant profiles
9 rules:
10 - name: deny-metadata-endpoint
11 match:
12 - domains:
13 - metadata.internal
14 - "*.internal.company.com"
15 actions:
16 block:
17 statusCode: 403
18 body: '{"error":"access to internal services is forbidden"}'1apiVersion: agents.kruise.io/v1alpha1
2kind: SecurityProfile
3metadata:
4 name: example-api-credentials
5 namespace: agent-demo
6spec:
7 selector:
8 matchLabels: {app: agent}
9 rules:
10 - name: inject-example-api-key
11 match:
12 - domains: [api.example.com]
13 schemes: [https]
14 paths: [{type: Prefix, value: /v1/}]
15 actions:
16 tokenTransformation:
17 type: ApiKey
18 failStrategy: Block # fail closed when the credential is missing
19 credentialRef:
20 secret:
21 name: example-api-credentials
22 apiKey:
23 targetHeaders:
24 names: [authorization]
25 value:
26 template: "Bearer {{ .Token }}"When NOT to use this
The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.
Want the complete reference?
Read official docsIndustry-standard certifications built by the people behind Linux and Kubernetes. Earn the CKA — the gold standard Kubernetes administrator cert. OpsCanary readers get 30% off year-round with code OPSCANARY3.
Get CKA certified →AWS Nitro Sandboxes: Elevating Pod Security in EKS
AWS Nitro Sandboxes provide a powerful solution for workload isolation in Amazon EKS, giving each pod a hardware-enforced security boundary. This ensures that even if one pod is compromised, it cannot affect others or the host system.
Harnessing OpenShell on Kubernetes: A Practical Guide for Platform Engineers
OpenShell offers a secure runtime for agents in Kubernetes, addressing the need for safe agent execution. With its unique Agent Sandbox resource, you can manage network access and policy checks effectively. Dive in to discover how to implement this in your cluster.
Mastering Isolation and Security in Kubernetes: Scale with Confidence
Isolation and security are critical in Kubernetes environments, especially when running untrusted code. By leveraging gVisor and microVMs, you can achieve robust security without sacrificing performance.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.