A couple of months ago, James Watters, CTO for Modern Apps at VMware, gave a compelling talk at Cloud Native Security Day on what he called “modern least privilege.” The basic concept is to apply the principle of least privilege across the DevSecOps lifecycle to properly secure modern apps. Modern least privilege is the strategy VMware is taking in developing our Tanzu portfolio of DevSecOps offerings. I’d like to dig into this strategy and share our perspective here.
I don’t think I need to underscore the importance of security. Events like the recent SolarWinds hack are well-known. In that case, hackers were able to insert malicious code into SolarWinds’ code repository such that SolarWinds unwittingly released this malicious code as part of their regular software update, which then affected customers as they updated. The challenge, though, is that security is often not on the top of developers’ minds. They’re more focused on solving the immediate business problem. While we must help developers put security top of mind, we should make the easy option also the secure option (developers, like most of us, typically take the path of least resistance).
Modern apps are more complicated than traditional apps – they have greater scale, change faster, are more distributed (i.e., no traditional security perimeter). While it may seem like this would make it more difficult to secure them, many of the innovations in the cloud native development space, when properly leveraged, can make many aspects of security easier by automating them and making them the default/easy option.
As the industry has adopted cloud-native applications over the past decade, a clear set of best practices has emerged. One of these best practices is known as the “3Rs” – repair, repave, rotate:
- Repair: repair vulnerable software as soon as updates are available.
- Repave: repave servers and applications from a known good state. Do this often.
- Rotate: rotate system credentials frequently, so they are only useful for short periods of time.
There are several principles of cloud native architecture that underpin the 3 Rs:
- Immutability: Once something is deployed, it should not be modified or reconfigured. Any new code, change in configuration, or anything other change should be made in source control and a new, immutable instance should be deployed. Least privilege means no changes after deployment.
- Ephemerality: Many traditional apps have components or instances (e.g., VMs) that live for months or years. This provides a large window of opportunity for a hacker to gain access to that app and leverage that access for further attacks. Cloud-native design principles, by contract, focus on ephemerality and minimizing the length of time an instance exists. Repaving continuously reduces the amount of time a hacker has to compromise a system. Least privilege means driving a hacker’s window of opportunity as close to zero as practical.
- Ephemeral Identity: A similar principle applies to identity and secrets – you don’t want anything long-lived as that provides hackers opportunities to leverage those credentials. Instead, you want automation that rotates credentials frequently. Least privilege again means driving toward zero.
- Event-driven Vulnerability Management: If you have a fully automated CI/CD pipeline and you have the right vulnerability management tools, you can connect them such that as vulnerabilities are discovered and fixes become available, the system can automatically kick off a repave. This becomes event-driven repaving for security issues. All automated, without the need for a human in the loop! Least privilege means lowering the time gap between discovery of a vulnerability and the patching of that vulnerability as close to zero as possible.
- DevX as Control (Shift left + DevX): Delivering a great developer experience means allowing the developer to focus on their business logic. Developers should be thinking about security, but ideally the DevSecOps platform just handles most of it for them. I.e. the security controls, as much as possible, are just built in. Least privilege means enforcing controls automatically and transparently wherever possible.
These principles come together in serverless apps. Serverless apps are immutable, ephemeral, and API first. But these principles can be applied to microservice and many other types of architectures. However, wherever possible, we strongly recommend using serverless runtimes.
The key to enabling the 3R’s and principles outlined above is to have the right DevSecOps platform:
Given this platform and the automation it enables, you can see how the 3Rs can be put into practice. Any number of events can trigger a repave. It could be a developer checking in new code, a Site Reliability Engineer (SRE) making a configuration change, or a security system detecting a vulnerability and automatically applying the fix. In all cases, it’s the same standard and secure process. In fact, you can start doing some cool stuff as you build more advanced policies on top of the automation. For instance, if your security system notices a vulnerability or misconfiguration, it can trigger a repave. But it again notices the app again has the same vulnerability or misconfiguration, it can trigger an alert to an admin as it’s a deeper or more subtle security issue. This enables the automated system to take care of most issues and only bubble up the tremendously important ones for a human to investigate. Least privilege means letting the automation do the work wherever possible.
So how do you get a DevSecOps platform? A holistic and well-integrated solution is required. The platform must have:
- Application frameworks with security
- API services and security
- Secure container build services
- Application services
- L7 application networking and security
- Kubernetes policy and lifecycle management, down to the OS
Today most customers I talk to cobble together their DevSecOps platform from many partial offerings from a variety of vendors. With Tanzu we are offering this platform “as a product”, i.e., ready to use out of the box, but with pluggability so you can swap out a particular component if you want (e.g., use your own container registry):
Code
The first step of the process is writing the code. As discussed above, the goal is to enable the developer to write their business logic and not much else. Ideally application frameworks can handle the other stuff and do so in a secure way, implementing all the appropriate security controls. Tanzu provides the Spring framework to deliver configuration management, session and authorization management, circuit breakers for cleanly handling dependent service issues, service integration, and mutual TLS between services. Additional frameworks and services solve problems around single sign-on, authentication and access control, secrets management, distributed tracing for complex distributed apps, and logging.
Spring Cloud provides additional capabilities such as an API Gateway, Config Server, and Service Registry. Tanzu API Hub promotes API-first design by creating a central place for viewing and managing all APIs within an organization. Put together, all this functionality provides developers with a great experience, allowing them to focus on their code, while ensuring the app has the required security functionality.
Build
The next step is turning the code into a container image or set of images. Tanzu Build Service is a secure container build services enabling vetted components via the secure software supply chain, reproducible build environments to ensure build machine configuration differences don’t affect build artifacts, and a minimal app image so that only necessary components are included (a sort of least privilege). Tanzu Build Service solves these problems by leveraging cloud native buildpacks, providing a governed build process for Java, .NET Core, Node.js, and Python apps. By automating a lot of work traditionally done by hand by a developer, we both improve the developer experience and improve security. Modern least privilege, again, means automating wherever possible.
Prepare
Once the container images are built, the overall application must be defined. This typically involves pulling in additional components, such as open-source software components. This is another place where problems can creep in, as many OSS (Open-Source Software) components in enterprise apps are not fully vetted and often downloaded directly from the Internet. Tanzu Application Catalog solves this problem by enabling known and vetted components to be easily used by developers. This is a notable example of making the secure option the easy option (modern least privilege!). Tanzu Application Catalog delivers golden image support, proof of provenance, and proof of testing, all core pillars of a secure software supply chain.
Deploy
Tanzu Mission Control provides Kubernetes cluster management across clouds. Apps need to be provisioned to different clouds, regions, and availability zones. Tanzu Mission Control ensures apps are deployed to the correct locations and properly secured and configured. It also provides a birds-eye view across all the different Kubernetes environments across clouds. It enables centralized policy management, so that irrespective of where apps are provisioned, you can be assured that they have the appropriate security and other policies.
Connect
Service meshes are being increasingly used because they provide a powerful set of capabilities around application continuity, resiliency, and, most importantly, security. Tanzu Service Mesh enables you to connect, monitor, and secure cloud-native applications. As we adopt API-first designs, API security becomes paramount. Modern least privilege means that all APIs must be locked down and secured properly. Typically, this is done by an API team, separate from the development team. But with Tanzu Service Mesh, API security policies can be applied as part of the pipeline, automatically. This enables strong security out-of-the-box.
Run
Tanzu Kubernetes Grid provides Kubernetes cluster lifecycle and security management. It embeds the core principles of repaving via its use of Cluster API. Cluster API is an open Kubernetes system for standing up Kubernetes clusters, with integrations to all major clouds and infrastructure providers. Via a declarative configuration, Cluster API can stand up a complete Kubernetes cluster, including the VMs that are part of that cluster. While Cluster API can repave the cluster as new Kubernetes updates come out, what is exciting is that we are extending Cluster API to also be aware of OS patches and updates and automatically repave based on changes to the OS. In this way, Tanzu Kubernetes Grid ensures a fully secure and compliant foundation for execution of your app.
Summary
We have an exciting opportunity to dramatically improve security in our enterprise applications by embracing these principles of modern least privilege. We are building in these controls and best practices into Tanzu so that you can apply modern least privilege to your organization. If you haven’t given Tanzu a look, please do check it out!
Comments