Assessing Kubernetes and its impact on application development in digital transformation
Cloud-native applications are fast becoming a necessity for companies implementing digital transformation due to their robustness, scalability and the way that container architecture lends itself to agile development. Being at the forefront of this revolution, containers and microservices have fundamentally changed how companies develop, ship and run applications, providing faster, more cost-effective approaches to developing applications in the cloud.
The leading mastermind behind the successful operation of containers is Kubernetes, originally developed at Google and since passed to the stewardship of the Cloud Native Computing Foundation (CNCF). Kubernetes has become the preferred orchestration platform facilitating development, scaling and deployment. Support has been robust: Since the CNCF accepted Kubernetes in March 2016, active contributors have grown 14,000% [CNCF].
This rapid move to Kubernetes also has its challenges: One report found that across the Docker and Kubernetes world, more than 40,000 container systems operate under default, insecure configurations and that for Kubernetes, 65% of reported cloud incidents were due to misconfigurations. Huge numbers of organizations are neglecting security through negligence or ignorance.
Kubernetes Security Assurance
The intersection of DevOps and Kubernetes has also necessitated new workflows. Continuous integration and continuous delivery (CI/CD) are being used in tandem with microservices and containers to break once-monolithic software projects and workflows into smaller, more modular and faster-moving components. In CI/CD, automated tools are also used heavily to test and deploy code into production quickly. These tools may check for bugs, configuration errors and security, and in general reduce the noise level, considering the fact that the CD is the right stage to detect and highlight relevant and actionable security issues. The CD Foundation is an example of the emphasis that companies put on the continuous delivery of these apps.
Enterprises looking to secure their CI/CD application pipelines seemingly have many security options, but are finding a new wrinkle in their plans: The CI, or constant integration portion of their process, turns out to have different security needs than the CD and production aspects of their pipeline. Furthermore, while there are many tools that masterfully support development and security for CI, there are relatively few that support security for CD and none that support CI/CD in a continuous, uninterrupted fashion. Companies are making do by repurposing their CI security tools to try to cover the security gap, one that those tools were not designed to protect.
What Companies Need to Complete Their Continuous Security
Why is CD different from CI? CD, or continuous delivery and deployment, is when the code has been approved as stable (and theoretically secure) and is deployed to production. At this point, a number of new factors come into play that distinguish CD from CI:
- The application in production is now exposed to outside influences such as hackers who may exploit previously unknown security flaws.
- Compromised services may begin behaving in ways that were not anticipated by CI security.
- Changes in the application code may have inadvertently caused drifts in the security configuration of the application.
Filling the Gaps Blocking Continuous CI/CD Security
Security-conscious developers see that what’s needed is a continuous security understanding and framework to protect the entire pipeline from CI through to CD and in production. Developers can’t protect only half of their software development pipeline, but that’s essentially what is happening these days due to the lack of awareness that CD is not CI and the two workflows require different security solutions.
As previously stated, security for the CI portion of software development is well-served while CD is underserved. There are excellent CD security solutions on the market, and what developers must do is either find a purpose-built CD security solution that complements their existing CI solutions or find a CI solution that has embraced extensibility to integrate with purpose-built CD solutions.
To combat this, the CD portion of application security must minimally do the following three things:
- Hunt for unsecured secrets. Kubernetes offers an excellent system for managing sensitive information such as passwords in the form of secrets. Sensitive information can be stored in encrypted secrets, and microservices can be given permission to use specific secrets for specific purposes. Restricted uses are prevented, limiting the damage that can be done by a compromised microservice. A good CD security solution must help detect when sensitive information has been wired in the open by developers and alert developers of the need to fix this vulnerability.
- Watch for security configuration drifts. No system can be 100% secure, so developers must decide what is the acceptable level of security versus performance for the application. Once decided, subsequent updates to the application may unintentionally cause the security posture of the application to drift. To prevent unintended exposure to risk, a CD solution must be able to take a baseline of the security configuration of the application and compare that to subsequent deployments. Any drifts should be flagged and reported to Ops.
- Role-Based Access Control (RBAC). RBAC gives you the ability to set permissions for specific sets of users over cluster resources. Since the release of Kubernetes Version 1.14, a new best practice is to use RBAC by default, knowing that users and resources won’t be able to perform sensitive operations without having the explicit permission to do so. As permission management is very complex, determine the risk associated with a specific workload and understand which users and what resources should have permission to perform sensitive operations.
Implementing a CD security solution that has these three capabilities—whether as a standalone solution to augment your company’s existing CI security or as an integration that extends your CI security—will provide a continuous security solution that will protect your application from the unique and disparate threats of CI and CD.