Managing cloud native apps at scale
Kubernetes is an open source container orchestration tool that automates many of the tasks required to run a containerized application at scale– tasks including container deployment, container-to-container communications, and load balancing across clusters of host servers (or nodes, as Kubernetes calls them).
Without a container orchestration tool like Kubernetes, it would not be feasible to run a containerized app for production purposes. Deploying and managing containers manually using the command line requires far too much time and concentration to be performed on a large scale.
Kubernetes is only one of several container orchestrators that have become available in recent years. However, Kubernetes has emerged as a leading orchestration solution due to its open source nature, its compatibility with a range of different container runtimes, including but by no means limited to Docker, and the rich community that has grown up around it since its release in 2015.
Kubernetes doesn’t manage security
While Kubernetes automates many of the tedious tasks required to deploy containerized apps, one critical thing that it doesn’t manage in most respects is security. Kubernetes has a few features that can help to secure a containerized app. When properly configured, it can enforce role-based access control policies, for example, and it can restrict the ability of a container to access resources on the host server.
Beyond these basic security measures, however, Kubernetes offers nothing in the way of securing an application. It doesn’t inspect the contents of a container for known security flaws. It doesn’t detect anomalous behavior within a containerized app that could signal a breach. It doesn’t secure nodes or harden networks against attack.
In short, Kubernetes is a container orchestration tool. It’s not a container security tool, and it would be a big mistake to assume that Kubernetes can defend your containerized app from security vulnerabilities.
Addressing Kubernetes security challenges
That’s why building effective Kubernetes security requires extra work and tools. You need to address the following potential security risks that Kubernetes can’t handle:
Least-privilege access control: Although Kubernetes has a framework for access control, not all access-control features are typically turned on by default. They may also not be configured to enforce least-privilege policies. For this reason, you should perform audits and compliance checks to enforce proper security configurations within Kubernetes.
Pod-to-pod communications: Default Kubernetes configurations should be checked to minimize the risk that an attack within one workload (or pod, in Kubernetes parlance) will spread to other pods. Locking down network communications and requiring authentication in Kubernetes are important steps for this purpose.
Container runtime: A container runtime is the special application, such as Docker, that executes containers. Kubernetes does nothing to harden the runtime against attack, or detect intrusions after they occur. You’ll need third-party tools to do that.
Container images: Detecting malicious code inside a container image requires a container image scanner, which is not a feature of Kubernetes.
Host security: Kubernetes takes the servers assigned to it and runs containers on them. Since it doesn’t do anything to secure those servers, you need to use other tools and processes to harden them and monitor them for security problems.