With the rise of DevOps, Kubernetes has become extremely popular and with good reason; it’s a brilliant platform. But securing Kubernetes is a complicated challenge – especially as you move from a single to a multi cluster deployment.
Kubernetes offers three main security tools:
- A network policy API which allows you to define security rules that discern which pods should be able to communicate with other pods. (By allowing only pods with explicit consent to communicate with one another, you create a Zero Trust model.)
- A role-based access control (RBAC), factored into the workload deployment on the control plane level, that allows you to define which users can administer the cluster, and list, get or create pods.
- Definition files in YAML format, to document metadata about the policy. Using this method, you define a specific pod with a selector on these labels, that is then able to communicate with the final pod that has those same labels.
These tools are solid enough, but they become much easier to use when augmented with a control plane like Aporeto’s.
Deploying your Kubernetes cluster
Inside Kubernetes, Aporeto enables network policies and fully automated single-cluster and multi-cluster deployments. As soon as you deploy your Kubernetes cluster, Aporeto springs into action to deploy what we refer to as the Enforcer – a userland process that resides on each host. The Enforcer is able to automatically access the network policy rules from a central control plane (the Aporeto backend), and seamlessly apply a set of security rules, which are applied to a Zero Trust networking model. This means that only the pods that should communicate with each other will be allowed to do so. (And by directly defining those network policies, you avoid the use of a stack of YAML files.)
Each time a Processing Unit (PU) – which can be a container, Linux process, or external service – attempts to access another PU or resource, the Aporeto Enforcer automatically creates a Trust Profile which travels along with the I/O request. (PUs can be running within Kubernetes or external to it, and can span hybrid cloud architectures or even span Kubernetes clusters.) The Trust Profile includes information such as who (user-id as verified by authentication), where (network address of requester), what (information about the service or resource being accessed), metadata (from Linux processes, Dockerfiles, Docker containers, Kubernetes labels, etc.), reputation (from ratings services), and behavior (from past history running in the environment).
Understanding Trust Profiles
Trust Profiles are hashed and cryptographically signed by the Enforcer, to ensure they are genuine and cannot be tampered with. Each Enforcer has been registered and been granted a signed certificate to create a “chain of trust”. You can think of a Trust Profile as a passport. Every connection request from every PU carries with it a Trust Profile which is used by the receiving Aporeto Enforcer to allow or deny the connection.
By automatically combining multiple factors into the Trust Profile, an unsurpassed security posture can be accomplished with zero manual effort, and it is always current, regardless of how dynamic the runtime environment may be. And because the Enforcer has visibility on all traffic, logs help to identify anomalous behavior, including possible security breaches or application bottlenecks.
An Aporeto security policy controls what a PU can do within the system. The syntax to define a new policy is intuitive, leading to better application security, visibility, and auditability. Better yet, Aporeto will generate the security policies for all PUs automatically by watching them run for a period of time. This saves SecOps a lot of work, and promotes full coverage of all interaction paths. To refine the security of the application, security policies can be easily inspected and edited. If encryption of data in flight is specified in a security policy, Aporeto automatically encrypts the traffic with no changes required for source code and no key management required.
With stock Kubernetes, network access policies are applied to containers based on labels. Aporeto uses this paradigm as well, as it eases administration at scale of a dynamic environment. However, where stock Kubernetes only limits traffic based on CIDR and Port, Aporeto utilizes the automatically generated unique identity of individual application components. This allows Aporeto to provide enterprises with security that better enables protection against malicious or unintentional security breaches, from within or without.
Better and More Thorough Security
Because it employs machine intelligence to generate security policies, Aporeto’s solution not only provides better and more thorough security, but its automation reduces complexity and saves SecOps time. Aporeto can be used with or without stock Kubernetes NetworkPolicy resources. It uses an open source, industrial strength, userland Enforcer that is easy to deploy and proven to scale, even for highly dynamic environments that potentially span Kubernetes clusters.
Aporeto is easier to use than network-oriented perimeter security based on Kubernetes NetworkPolicy resources, and provides SecOps with clear visibility of the application’s security posture, not only across Kubernetes workloads and clusters, but across services and resources that are not running on Kubernetes.
Aporeto is one amongst a variety of third-party network plugins that can enforce network policies within Kubernetes. But none of the others provide such a powerful, secure and easy-to-administer solution for hybrid cloud workloads. None of the others offer such an effective way to improve an organization’s security posture – even across clusters in different security zones. For more information on Defining Security for a Kubernetes Deployment, read our whitepaper.