Kubernetes 1.10 was officially released recently, with many new enhancements and improvements. This version of Kubernetes, which is lighter on the security side compared to the recent 1.9 and 1.8 releases that were very security focused, offers several new worthy security related features.
Limit node access to the API
In 1.10 you can limit node access to API server using the NodeRestriction admission plugin. Nodes are now configurable to be so that they may only modify their own Node API object or pod objects bound to the node, and only retrieve secrets and configmaps referenced by pods bound to the node.
Read more about NodeRestriction here.
External client credentials provider (Alpha)
This new alpha release feature allows client tools to integrate with external authentication providers, e.g., LDAP and Active Directory. This is achieved through a new client-go credential plugins option, that allows to integrate authentication plugins into the Kubernetes client tools.
The following procedure illustrates the use of the new client-go credential provider to authenticate against Kubernetes with LDAP credentials:
- A user issues a kubectl command.
- Credential plugin prompts the user for LDAP credentials, exchanges credentials with external service for a token.
- Credential plugin returns token to client-go, which uses it as a bearer token against the API server.
- API server uses the webhook token authenticator to submit a TokenReview to the external service.
- External service verifies the signature on the token and returns the user’s username and groups.
This will be useful to many enterprises that manage access by user groups in LDAP or Active Directory, and would want to extend those group controls to govern privileges in Kubernetes clusters.
Read more about client-go credential plugins here.
TokenRequest API (Alpha)
The TokenRequest API is an Alpha feature in 1.10. It provides the groundwork for much needed improvements to service account tokens; this feature enables creation of tokens that aren’t persisted in the Secrets API, that are targeted for specific audiences (such as external secret stores), have configurable expiries, and are bindable to specific pods.
This is a welcome addition, since it obviates the need to create a service account for every little request – a much more scalable and secure approach.
Sharing PID namespace between pod containers (Alpha)
New functionality that allows sharing PID namespace between pod containers. This is controlled using a new ShareProcessNamespace boolean field in the POD spec. The default is “false”, means that each container in the pod will run with a different PID namespace. Setting to “true” all containers in the pod will share the same PID namespace.
The following example shows a pod with two containers, nginx and alpine, running with shared PID namespace. The alpine container is assigned with SYS_PTRACE capability, allowing the alpine container to send SIGHUP signal (that requires ptrace) to the nginx process:
Pod Security Policy with a dedicated API group (Beta)
The Pod Security Policy is still in beta, but now has its own API group. This beta release lets administrators decide what contexts pods can run in. A use-case for Pod Security Policy is to prevent unprivileged users from creating privileged pods — that is, pods that can perform actions such as writing files or accessing Secrets — in particular namespaces.
This is key for ensuring least privileges, preventing privilege escalation, and maintaining segregation of duties.
Performance Sensitive Applications
Some features that matured from Alpha to Beta – the CPU manager and huge memory pages:
The CPU manager allows user to request exclusive cores. This helps performance in a variety of use-cases, including network latency sensitive applications, as well as applications that benefit from CPU cache residency.
The huge memory pages feature allows pre-allocation of huge pages by applications in a Pod. Use of Huge Pages is a common tuning recommendation for databases and JVMs.
Conclusion
It’s clear that as Kubernetes is being widely adopted, there’s greater demand for enterprise-grade features, including security. At Aqua will continue to invest in making deployments more secure by default, and in making it easier to manage and enforce security policy at scale.
To learn more, check out our Kubernetes security page.
