You have provisioned identities to all your machines— apps, Kubernetes clusters, cloud workloads—and you have also set up your machine identity management program in accordance with established best practices. You think to yourself “all is fine, I can now relax.” Not so fast!
The cloud ecosystem is not a static one. Instances and machines come and go. How can you be sure that your machine identity management program is as effective tomorrow as it is today? Welcome to the world of configuration drift! Spoiler alert: it is not as bad as it sounds…
What is configuration drift?
Organizations have always been working to alleviate misconfigurations in their environments. Unfortunately, configuration drift in the cloud is inevitable. Even companies with the best of intentions, who have worked through cloud adoption scenarios and based their infrastructure on the well-architected frameworks, frequently run into changes from their baseline.
Configuration drift occurs when the actual known state of the infrastructure differs from the last defined configuration. There are a variety of reasons why this can happen, and the consequences of drift vary significantly—from simply being an annoyance to causing drastic failures in security and production.
Drift can occur by adding or removing resources, like containers, or by making changes to existing resource definitions. Configuration drift isn’t necessarily bad, but with the varying severity of consequences mixed with the speed of the cloud, awareness is vital as well as having a process in place to manage unintended, costly misconfigurations in the cloud.
The growing use of various container and serverless technologies could result in a configuration drift. A survey by the Cloud Native Computing Foundation (CNCF) in 2019 found that 41% of organizations were using serverless technologies and 84% of organizations were using containers.
According to the findings of another survey, cloud security posture drift is a common phenomenon seen in over 90% of cloud deployments. The same report found that 77% of the cloud resources that drifted from their secure baseline included instances (37%), application load balancers (19%), security groups (15%) and cloud storage services (5.5%). In some cases, these changes are authorized and legitimate, whereas in other cases, the changes introduce risk.
How is drift related to machine identities?
The accelerated digital transformation of the past two years has resulted in a dramatic growth of machines—and in their corresponding identities. This increase has complicated machine identity management, leaving organizations more vulnerable to certificate outages and credential attacks.
A recent report indicates that almost 75% of the surveyed organizations are very concerned about the time and effort required to manage all these certificates. These concerns are not unjustified—more and more devices are being added to the corporate network, while the ephemeral nature of Kubernetes clusters requires constant vigilance to provision or revoke certificates.
This evolving ecosystem creates challenges in managing machine identities. The same report highlights that an organization has an average of 1,200 unmanaged certificates, resulting in increased outages. A sizeable 75% of businesses reported that they experienced outages because poorly managed certificates expired unexpectedly.
Lack of visibility and consistency is a top reason for configuration drift
A common denominator behind all posture drifts is the lack of consistency and visibility across all your resources that need a machine identity. The introduction of shadow IT—mostly in the form of unregistered SaaS apps—makes it difficult for security teams to obtain clear visibility over the enterprise resources and their associated machine identities.
In addition, ephemeral containers and Kubernetes clusters create an extra layer of difficulty. These services use digital certificates to securely communicate with each other. With clusters coming and going at high speed, their machine identities need to be provisioned, revoked and managed at the speed of light. If a single cluster is left unprotected, it could become the pathway for attackers to manipulate the cloud native ecosystem and infect cloud apps.
It’s no wonder that first and foremost best practice of NIST SP 1800-16 for managing machine identities and digital certificates is to build a consistent inventory of all enterprise digital identities. You cannot defend what you don’t know exists.
How can organizations overcome configuration drift?
The solution is to deploy a machine identity management platform that provides continuous and automated monitoring, control, consistency, and intelligence into all your machine identities—especially those in cloud native environments. This will help ensure that:
- Cloud native machine identities comply with corporate security policy
- Cloud native machine identities are consistently configured across all cloud-native environments, no matter where they are hosted
- Visibility into how many cloud-based machine identities are in use, have been issued, and what their current status is and if there are any abnormal or unauthorized additions to your posture
Using the continuous process, the security and cloud-native platform teams should work together to increase the percentage of systems and identities that are monitored and then should remediate the systems where configuration drift occurs. Maintaining minimal drift helps to maintain the secure hardened state of the business systems, which directly assists with the overall risk posture of the organization.
Venafi TLS Protect for Kubernetes is the cloud-native solution that can help you minimize configuration drift for your machine identities. TLS Protect for Kubernetes helps you take control of your cloud native machine identities and eliminate outages to applications, services, and security infrastructure.