Container and Kubernetes security can be difficult. It can be daunting to try and monitor and protect a container ecosystem of hundreds or thousands of containers spread across a dynamic hybrid or multi-cloud environment. Ultimately, though getting the desired cybersecurity outcome is often a function of making sure you ask the right questions in the first place. With the right questions, you can determine where your containers or Kubernetes are exposed to risk and what your options are to mitigate that risk and provide the best possible protection.
With that in mind, here are the top 10 questions you should ask your team about container and Kubernetes security:
1. Where are the container images coming from?
You need to ensure that only trusted assets are deployed. To minimize risk, you should limit containers to images from internal repositories or secure third-party image repositories.
2. How long ago were the images scanned for vulnerabilities?
Part of the reason for using container images from a trusted source is the assumption that those images have been scanned for vulnerabilities. However, new flaws are discovered all the time, so it’s important also to consider how current the vulnerability scan is. Frequent scanning is essential to container security.
3. Which of your containers are impacted by known vulnerabilities, and what’s their severity?
DevOps culture and container ecosystems are built on open source code and rely heavily on modules or code snippets from open source projects. New vulnerabilities are discovered almost daily, and it’s important once new vulnerabilities are found to be able to find affected containers not just in images but in running deployments as well—and fast.
4. Are any of these containers in production impacted by a known vulnerability?
It’s particularly urgent to be able to identify any containers running in production that contain known vulnerabilities so you can take immediate steps to patch or mitigate the flaws. Beyond finding where you have a vulnerability, you also must be able to determine whether it’s been (or is actively being) exploited.
5. Which vulnerable running containers or deployments should be prioritized first for remediation?
Knowing you have 68 instances of a critical vulnerability won’t in and of itself help your team. With limited resources, you can’t put out every fire simultaneously. You need content to help you prioritize the threats. Knowing which three or five instances present the biggest risk—based on attributes such as internet reachability, app criticality, or running as root—will ensure those get fixed quickly.
6. Which deployments are using privileged containers, meaning they have full access to the host operating system?
Privileged containers, like privileged accounts, represent a greater risk than standard containers. Privileged containers have root or admin rights that allow them to interact with the host operating system. You need to know where you have privileged containers so you can monitor them more closely and ensure they are a top priority when mitigating threats.
7. What container applications services are exposed outside of the Kubernetes cluster?
Container application services that are exposed externally from the Kubernetes cluster increase risk and offer a window for attackers to exploit. With “default allow” network connectivity native to Kubernetes, you need to minimize potential attack vectors by making sure your team has turned off unnecessary communication paths.
8. Can we tell which processes are running in any container in any cluster?
Identifying and patching vulnerabilities in container images is a great step, but you also need to be able to monitor containers in production to identify suspicious or malicious activity, so you can take immediate action to mitigate the threat. Identifying suspicious processes enables you to highlight compromised containers so you can take the appropriate action.
9. Which network communication pathways are active but are not being used in production?
One of the essential principles of effective cybersecurity is to minimize the attack surface. That holds true for containers and Kubernetes as well. If you have network communication paths that are not being actively used, they need to be identified and shut down. These insights will help your team reduce the attack surface.
10. What team in the organization owns a particular running application?
It’s not about pointing fingers or figuring out who to blame. You should know which team has ownership of containerized applications running in your Kubernetes cluster so you can communicate and coordinate efforts when issues arise. Ensuring effective remediation and minimizing the impact on productivity will require the help of this team.
The rise of Docker containers has not only enabled microservices and DevOps practices but has also made Kubernetes indispensable. This has increased collaboration between developers and security teams. Properly securing containers comes down to following known security best practices and embedding security into each phase of the container life instead of treating it as an afterthought.