Continental Innovates with Rancher and Kubernetes
Kubernetes provides the freedom to rapidly build and ship applications while dramatically minimizing deployment and service update cycles.
However, the velocity of application deployment requires a new approach that involves integrating tools as early as possible in the deployment pipeline and inspecting the code and configuration against Kubernetes security best practices.
Kubernetes has many security knobs that address various aspects required to harden the cluster and applications running inside. Ops teams need to understand those security knobs and keep track of their implementation while ensuring the agility and efficiency of deployment cycles.
What is Kubernetes hardening? And what are the security guardrails to live by?
First, the goal is to minimize the permissions and network access, filesystem access and API server access to the minimum required by the application without breaking it. This translates into protecting your deployments with continuous security and configuration checks, as early as your build, from development through production, following these simple milestones.
Scan the Kubernetes cluster’s application configuration and deployment files to ensure you’ve implemented security best practices. Make sure no misconfigurations slipped through the deployment pipeline and negative security drifts do not happen over time – which will help you gain a better understanding of your distributed and complex Kubernetes projects.
Monitor Kubernetes network policies and see how they are layered on top of the security groups, enabling policies to be easily tuned and refined through application labeling and applied to the relevant tier in the organization.
Control who can access the Kubernetes API server. By default, Kubernetes creates a service account for every pod created. In the majority of the cases, you don’t need those permissions, but often those exact permissions would be one of the prerequisites to exploit the Kubernetes API server.
There are quite a few security aspects to consider around Kubernetes, including Pod Security Policies (PSP), network policies, API server access privilege and many more.
Let’s focus on two examples of known and prevailing risks:
Kubernetes Common Vulnerabilities and Exposures (CVE)
While Kubernetes drastically simplifies the orchestration of your most-sensitive containerized environments, it’s not bulletproof to critical security vulnerabilities that require quick detection and even faster response. A great example is a relatively new Kubernetes control plane vulnerability (CVE-2020-8555) that we recently covered here, which affects the kube-controller-manager. Ultimately, it can allow an attacker to bypass authentication controls and gain access to sensitive data.
Hunting Misplaced Secrets / Excessive Secret Access
The Kubernetes secret object stores and manages sensitive information, such as passwords, OAuth tokens and API keys. Placing this information in plain text or in the wild (like config maps) can make it easily exposable to unauthorized users or other workloads. It can ultimately enable a threat actor to access the asset this secret is supposed to grant.
The increasing complexity of distributed environments opens the door to higher security risks and calls for new and innovative mitigation strategies.
This is why we teamed up with Rancher and integrated the Alcide Advisor, a Kubernetes multi-cluster vulnerability scanner designed to detect hygiene and conformance drifts from the CI/CD pipeline.
This integration adds a multi-cluster security automation layer on top of Rancher’s orchestration capabilities. DevOps and SecOps teams can continuously protect their Kubernetes deployments by leveraging Rancher’s resources and getting real-time data feed from Alcide directly into their Rancher account.
The Alcide Advisor is a Kubernetes multi-cluster vulnerability scanner that covers rich Kubernetes and Istio security best practices and compliance checks, much like the ones we covered earlier. The Advisor is currently available via Rancher’s repository, simply packaged via Helm chart, allowing users to gain access and run a full cluster scan at early stages in a matter of seconds. It is also available directly from Rancher’s Apps Catalog.
The example below is a short snippet from a scan we ran on a demo cluster, showing some of the checks we are validating throughout the scan and, ultimately, presenting a summary report of the findings. This generated report can also be viewed as an HTML page:
Alcide Advisor default profile scan and results
While there are several tools that can perform scans in earlier stages, remember that they can also render several configurations and resources like secrets, image sources and RBAC settings. As a result, pre-deployment scans will not necessarily give you the most accurate mapping of issues you should aim for.
Automation pipelines end up provisioning first- or third-party container images, wrapped with Helm charts or Kubernetes resources, and inject configuration and secrets into various locations that are implementation-specific.
In addition, configurations like network policies and PSPs will not be detected before the CD stage. Kubernetes also includes admission controllers that can mutate deployed resources, which may lead to negative drifts among deployed resources and configurations.
Continuously maintaining a high level of hygiene across multiple clusters is essential and should be tightly enforced throughout the CI/CD pipeline.
There are some key components to track, like cluster infrastructure, resources and workloads hardening and more.
Combining Rancher’s management capabilities with a tight security layer by Alcide will ultimately accelerate operation processes and empower both DevOps and security teams. By leveraging Alcide with Rancher, you can establish a baseline of what is currently running in a cluster and ensure the existing environment satisfies expectations.