Microservices fuel rapid release cycles by removing single points of failure (SPOFs) and the ability to extend functionality without unnecessarily affecting other parts of the application. To realize these benefits, organizations use containers (and container orchestration) to manage the lifecycles of individual components and the host’s resources to ensure the microservices’ availability. Orchestration tools can manage multiple clusters and are the key to the type of scalability that makes microservices appealing for enterprise applications.
Kubernetes is a container-orchestration system for automating application deployment, scaling, and management. It can manage clusters of Docker containers and organize containers into groups (aka “pods”). While powerful, Kubernetes expands your attack surface and threat profile if not implemented and configured correctly.
While there are many ways to secure Kubernetes, the following are three hard-hitting best practices that can reduce risk exponentially:
- Leverage security controls: several built-in controls can reduce unnecessary access
- Use metadata concealment: this prevents sensitive information from leaking to the application within a container
- Regularly install updates: like any software application, Kubernetes and associated software can (and does) contain undiscovered vulnerabilities
Leverage Security
Controls In addition to keeping the software up to date, Kubernetes provides multiple security controls, such as Role-Based Access Control (RBAC), Security Context, and Network Policies, to reduce unnecessary access. These should all be configured to match the requirements of your applications and your organization’s policies. RBAC is standard and enabled by default in recent versions of Kubernetes. As with all role-based authorization, you must clearly define roles and apply the principle of least privilege when granting access. You can only grant permissions to roles in Kubernetes; there are no “deny” rules. A role in Kubernetes is a set of granted permissions.
Kubernetes provides a distinction between Roles and ClusterRoles:
- Role: scoped within a specific namespace
- ClusterRole: granted access to cluster-wide resources
Roles are assigned to users or other subjects, such as service accounts or groups, using RoleBindings. ClusterRoles may be assigned using ClusterRoleBindings. Assigning a ClusterRole using a regular RoleBinding will limit the scope of the ClusterRole to the specific namespace specified by the RoleBinding.
Security contexts are specific to pods or containers. They specify the user IDs that the container or pod runs as, whether privilege escalation is allowed, and various Linux settings and restrictions. Network Policies perform a similar function to firewalls–they specify the allowed connections. Connections that are not permitted by any Network Policy will be rejected. To use Network Policies, you will need a provider that supports them. In some cases, you might have to enable support for Network Policies before you can use them.
Defining a pod security policy applies security controls to all the pods in the cluster. It is created like any other cluster-level resource. It restricts the system privileges of containers, the ability of containers to access system resources, and Linux kernel capabilities provided to the containers.
Use Metadata Concealment
Metadata concealment can prevent sensitive information from leaking to the application within a container. The metadata in this context refers to the information used to configure the node, but some might be useful when executing attacks. A Kubernetes node is either a bare-metal machine or a virtual machine that runs pods and is a member of a Kubernetes cluster. Note: If metadata is not concealed, a compromised workload might be able to impersonate a node by extracting the node’s identity document and token. Other privilege escalation vulnerabilities might be possible due to the exposed sensitive metadata.
Metadata concealment is a defense in depth measure because some other vulnerability must be present for an attacker to access the metadata from within the container. Even when metadata concealment is enabled, the containers will access metadata that is not security-sensitive and thus function correctly.
Install Updates for Kubernetes Vulnerabilities
As with any third-party application, it’s essential to protect against known vulnerabilities by regularly installing updates and monitoring official channels for notifications about new releases. For example, a dangerous vulnerability was discovered in the past that allowed executing arbitrary commands on the pods with the credentials of the API server [1]. Kubernetes namespaces can mitigate this risk by logically separating different workloads and applying security controls to the individual namespaces. These security controls include authorization rules, resource quotas, and network policies. Segregating the workloads into various namespaces helps to reduce the impact of a compromise and configures the security controls in compliance with your organization’s requirements and policies.
As illustrated, while Kubernetes provides robust orchestration capabilities, careful configuration and best practices must be applied to properly secure. Security Innovation can help reduce cloud risk with our expert assessment and the industry’s most comprehensive cloud and DevOps skills training for software teams.
About Lisa Parcella, Vice President of Product Management
With a background in security awareness, product management, marketing communications, and academia, Lisa leverages her vast experience to design and deliver comprehensive security-focused products and educational solutions for the company’s diverse client base. Before joining Security Innovation, Lisa served as Vice President of Educational Services at Safelight Security. She holds a B.A. from the University of Vermont and an M.A. from Boston College. Connect with her on LinkedIn.
