More and more organizations today use microservices and distributed architectures to achieve agility and scale; the most recent CNCF survey, for example, finds that more than 50% of organizations are using Kubernetes in production. At the same time, we’re seeing a growing number (including most of our customers), adopting a multi-cloud strategy – due to changing business needs. Enterprises now require the ability to allow different parts of the organization to use best-in-class functionality for their use cases, or an acquisition driven business model. They deploy their applications into the public cloud (Google, Amazon, Azure, etc.) as well as on-premises, including both Kubernetes and virtual machine-based workloads.
The Platform and DevOps teams in these organizations have to model distributed and multi-cloud applications and services accessible from anywhere and anytime to be agile. These innovations help with speed and growth, but require a focus on robust security and compliance to avoid introducing vulnerabilites. Most of the organizations we talk to are gradually evolving in their DevOps journey and have started adopting DevSecOps by integrating security checks into their software development lifecycle. At the same time, they’re enforcing runtime policies like end-to-end encryption with mutual TLS and auditing all changes in their application networking.
Operating in the cloud requires the implementation of zero trust security. Why? Consider this framing question: “The attacker is already in your network; how can you limit the damage they can do?” In a thoroughly networked world, you can no longer count on keeping attackers out; you must protect data, metadata, and code even once the attacker gets into what was formerly a trusted network environment.
You need a platform with carefully enforced encryption in transit, but also much more:
- Pre-runtime security: a secure software supply chain
- Runtime security: encryption in transit, also AuthN and AuthZ
- Continuous assertion of system state: proof of enforcement, logs, metrics, and telemetry
- Administrative support for security: least privilege – authenticate, authorize and audit
In this article, we will describe how the secure software supply chain implemented with a product like Tanzu Application Platform (TAP), combined with a zero trust application connectivity platform such as Tetrate Service Bridge (TSB), will allow application, platform, and information security teams to effectively manage and verify policies for the entire organization.
Pre-Runtime with Tanzu Application Platform
From the VMware site: “VMware Tanzu Application Platform is a modular, application-aware platform that provides a rich set of developer tooling and a prepaved path to production to build and deploy software quickly and securely on any compliant public cloud or on-premises Kubernetes cluster.”
With Tanzu Application Platform (TAP), application development teams are able to compose their software supply chains with the tools they are comfortable with, while the platform and security teams get the ability to include the required best practices configuration checks and security scans to enforce governance – all without giving up agility.
As an example, I have the components for the bookinfo app building whenever the source code changes or one of the base images has been updated – for example, due to a CVE patch. The flow looks like this:
Only when all the configured steps in the pipeline have passed the platform and security checks do we push and tag a new version of the container images into the registry and then automatically deploy it to our runtime environment for testing. This secure software supply chain is providing us continuous deployment!
Next we need to securely deliver traffic to the new version – we’ll use Tetrate Service Bridge to do this safely and quickly.
Runtime, Continuous Assertion, and Administration with Tetrate Service Bridge
Tetrate Service Bridge (TSB) enables security, agility, and observability for all edge-to-workload applications and APIs via one cloud-agnostic centralized platform. It provides built-in security and centralized visibility and governance for platform owners across all environments, including any cloud and on premises, yet empowers developers to make local decisions for their applications. TSB adds a highly functional management plane to service mesh implementations, collaborating with Istio as the control plane and Envoy as the data proxy.
As a service mesh management plane, TSB provides you with a single place to manage your entire infrastructure. It maps to your existing organizational structure and enables you to provision access rights according to your already-established teams and their needs. When you set up TSB, you can ingest your existing employee directory, including employee roles and per-employee information. You can then set policies by employee roles, assign access to resources by team, and more.
In TSB, a Tenant is a group of individuals or teams that share resources and operate within a set of Workspaces. Tenancy in TSB is designed to create boundaries for access to resources, with the ability to configure them safely and without affecting other teams. You can assign teams – such as the Infosec Team or individual app development teams – to multiple Tenants within TSB. The resources aTenant owns are further divided into workspaces, which are usually assigned to individual teams. The permissions you assign to teams on a tenant will be inherited down so they can make changes to all workspaces in that tenant too.
Note: To better understand how Tenants and Workspaces interoperate in TSB, see the documentation on tenancy. (https://tetr8.io/tenancy)
Key takeaway: Ownership, Abstraction, and Hierarchy enable policies at scale – With TSB you can set cross-cutting policies, as well as delegate down permission and responsibility all the way to application development teams.
How the Infosec Team Sets Secure Defaults and Enforces Policies, Including Encryption with mTLS
TSB sits at the application edge and is responsible for controlling request-level traffic across all your infrastructure – multi-cloud, Kubernetes, and traditional compute clusters – and for providing north-south API gateway functionality.
With TSB, Infosec can take security configuration out of the application code stack and put it in the transparent network layer where it belongs – avoiding using the developer’s bandwidth to change code for security. The DevOps team can now deploy the application faster, meeting business needs, while Infosec has central control of security policies for all services.
In the following example, our Infosec Team has mandated that the default Istio setting of PERMISSIVE is not acceptable and we will only allow traffic that uses mutual TLS. This setting can be applied hierarchically, in this example at the Tenant level, and all workloads deployed will automatically inherit and enforce mutual TLS-authenticated connections.
Key takeaway: Configuration abstraction makes it easier to Administer Policy – We can write policy about Tenant or Workspace authn/authz and translate to namespaces and service accounts at runtime.
Using the TSB UI, we can view the topology of our service calls and even filter the results to focus on the reviews and ratings services for the bookinfo application. For example, in the diagram, we have the new ratings-v2 application automatically being built, scanned, and deployed, but we do not yet have any traffic hitting the new version.
TSB allows us to view topology holistically or to use filters to view specific services.
Traffic Management for Application Teams
Our application team is now ready to leverage the traffic management capabilities of the service mesh to begin sending traffic to the new version. Our developer, Zack, would like to follow a canary deployment. While he could update the configuration in the UI, he prefers to use the TSB CLI, tctl, to apply the configuration change. The platform team has granted the required access to Zack to manage traffic configurations for their bookinfo application.
After Zack has logged in, he can apply these desired canary settings using the TSB ServiceRoute API:
$ tctl apply -f ratings-service-route.yamlTSB will then create the required Istio objects in our workload clusters – in this case, the VirtualService and the Destination rule – so that traffic is now sent to both subsets for the ratings service, v1 and v2.
Returning to the topology view, Zack can now verify the traffic is being split as expected 90/10. In addition, this view highlights that the service calls are enforcing mTLS between the instances, as indicated by the padlocks.
Remember, our Infosec Team has mandated that the default Istio setting of PERMISSIVE is not acceptable – we will only allow mutual TLS traffic. This ensures that only workloads with valid mesh identities can make calls to our new version of the service. The application team can also view the service metrics to compare the performance of the different versions of the ratings application.
Tetrate Service Bridge has powerful audit logs that show everything that happens to a TSB resource: who did what and when, on each resource. It also gives insights on the different stages of its config. Checking the Audit Logs, we can see that Zack applied a change to the ServiceRoute and we can even drill down and see a diff of the changes he made.
Additional Security Options Delegated to Application Teams
What if we also want to delegate fine-grained security options to the application teams? We know that only authenticated workloads in the mesh can access ratings-v2, but we want to be even more specific and authorize exactly which services are allowed. The platform team can grant the application team permission to update only the authZ policies for the security group in their application workspace. (For deeper coverage of authentication with Istio, see this blog post.)
Key takeaway: Istio lets us bound attacks in space and in time. Runtime encryption, authentication, and authorization reduce the attack surface exposed by our applications.
Zack can now add the authorization policy. However, he will not be able to override the authentication settings that were inherited from the Tenant settings we mentioned above.
$ tctl apply -f bookinfo-secure-default.yamlWith these security settings in place, the application team is now enforcing fine-grained permissions for authN and authZ in the service mesh. As with the traffic management settings, these policy changes are recorded in the audit logs, so we know who changed what and when.
Conclusion
We have demonstrated that combining a secure software supply chain with an enterprise service mesh enables you to monitor, secure, connect and manage services consistently – this limits the damage that can be done by an attacker who gets into your network. The outcome is a safer, more secure infrastructure.
If you are in the early stages of moving to a service mesh architecture, a platform like TSB can make the move much easier and less susceptible to errors. If you are already running Istio at scale, a platform like TSB can save you a great deal of time and effort while reducing errors and improving governance. You can contact Tetrate for more information.