Why Certificate Rotation Matters to Your Kubernetes and OpenShift Clusters' Security
Kubernetes and OpenShift clusters rely on several secure certificate chains and credentials for security
By David Bisson02/08/2021
So, why is this happening?
Organizations are increasingly using containers to fuel their digital transformations. As noted by Google, containers come with software libraries, programming language runtimes and other dependencies that are necessary for running an application. When added to the fact that containers can run on different OSes and on virtual machines, these elements make it possible for developers to create more consistent environments in which to run their apps. Such predictability translates into better productivity for organizations overall.
Where Kubernetes and OpenShift Fit Into the PictureMany organizations are realizing that they can’t manually manage their growing number of containers. In response, they’re turning to container orchestration services to help with the management process. Today, Kubernetes is the most popular solution. Indeed, CNCF found in its study that 78% of firms were using it in some form.
A portable, open-source platform, Kubernetes helps administrators to manage their containerized workloads and services using declarative configuration and automation. The idea behind Kubernetes is to administer all of an organization’s deployed containers in such a way so as to ensure that there is no downtime. Kubernetes facilitates this work by using load balancing to distribute the container network traffic, to change the actual state of the deployed containers to a user-defined desired state at a controlled rate, and to kill containers that don’t respond to a health check set forth by the administrator.
Even so, most organizations aren’t using Kubernetes to its full potential. Volterra released a 2020 report in which it found that 56% of its respondents were using the platform. But a closer look revealed that just 10% of those survey participants were running a majority of apps in the platform. More than half (57%) of organizations cited security and connectivity challenges as the reasons why they were using Kubernetes to run less than 10% of their business apps. The same was true for 88% of respondents who had deployed less than 25% of their apps with Kubernetes.
While some are choosing to hold back on their engagement with the platform, other organizations are choosing to partner with vendor-managed Kubernetes platforms to help them address those challenges. Red Hat OpenShift is one such platform. OpenShift manages clusters that use control planes for maintaining a cluster’s overall state and worker nodes for running containers. This enables OpenShift to positively contribute to the security of organizations’ Kubernetes deployments. It does this by vetting third-party integrations and providing monitoring, alerting and/or logging capabilities, among other security functions.
TLS and the Need for Certificate RotationThe fact that both Kubernetes and OpenShift rely on clusters is important to organizations’ digital security. Indeed, both platforms use Transport Layer Security (TLS) to secure container network traffic. This measure helps to protect the content of the traffic against those who might seek to intercept it.
The risks don’t end there, however. StackRox highlights the fact that malicious actors can target the digital certificates used by organizations to secure their traffic. As quoted in a blog post:
Kubernetes and OpenShift clusters rely on several secure certificate chains and credentials for security. If sensitive keys or certificates are compromised, the integrity and safety of the entire cluster and its workloads may be placed at risk. Additionally, many security policies and compliance certifications require regular rotation of encryptions keys and credentials.
Organizations therefore need to make it a point of rotating their OpenShift and Kubernetes certificates. When it comes to OpenShift, organizations need to remember that the service Certificate Authority (CA) certificate remains valid for 26 months and automatically rotates when it is set to expire in less than six months. The previous service CA certificate will remain valid for the remaining six months, thus giving administrators the opportunity to refresh their key material by updating the cluster.
If admins don’t do this, they might need to manually rotate the service serving certificates created by the service CA certificate. They can do this by following OpenShift’s documentation and deleting the corresponding secret. The platform will respond by creating a new secret, which will result in a new certificate. Administrators can also manually rotate the service CA certificate so long as they restart the cluster afterwards in order to avoid a temporary service disruption.
As for manually rotating their Kubernetes CA certificates, the platform’s specifications requires organizations to have a Kubernetes cluster along with a kubectl command-line tool that’s configured to communicate with their cluster. Just as long as they back up their certificate directory along with the configuration files and necessary files.
Aside from certificate rotation, organizations can take other steps to secure their clusters with Kubernetes and OpenShift. They can do this by following the platforms’ security best practices found here and here, respectively.
All information in this article is provided to you “as is” and represents the views of the authors. TechChannel cannot guarantee or imply absolute reliability, serviceability or function of the information herein.
David Bisson is an information security writer and a contributing writer to Bora.