Create Safe Perimeter Boundaries for Development Teams with Workspaces
Weave GitOps Workspaces is a new feature that enables multi-tenancy so platform engineers can scale their GitOps workflows across numerous development teams.
We are excited to announce the release of a new feature that brings greater control to cloud-native operations at scale. Weave GitOps Workspaces now allows platform teams to define custom environments for application developers and development teams. Workspaces benefit both the platform team as well as application development teams. Platform teams gain more control over environment creation, and they can enforce security guardrails, enabling dev teams to work within pre-approved, safe environments.
This is a continuation from a previous post we recently published on multi-tenancy. In that post, we gave an introduction into multi-tenancy, why it is important, and the various options available. Do read that post for more background understanding of the concepts described in this one.
In this post, we start with the concept of tenancy for cloud-native systems, which is what Weave GitOps Workspaces is based on. We look at a DIY approach to tenancy, and then explain how Weave GitOps Workspaces greatly improves on it. Let’s begin with a simple definition of tenancy from the early days of cloud computing.
Options for implementing cloud-native tenancy
There are multiple ways to implement tenancy, and which you choose will have a big influence on how easy or difficult it is to manage tenancy. Let’s look at each of the options in detail.
DIY tenancy based on Flux
Flux is a continuous delivery tool that’s based on the GitOps approach. Before we get into how Flux handles tenancy, let’s get a quick overview of what GitOps is.
GitOps is based on 4 fundamental principles as defined by the OpenGitOps project.
- Declarative: A system managed by GitOps must have its desired state expressed declaratively.
- Versioned and Immutable: Desired state is stored in a way that enforces immutability, versioning and retains a complete version history.
- Pulled Automatically: Software agents automatically pull the desired state declarations from the source.
- Continuously Reconciled: Software agents continuously observe actual system state and attempt to apply the desired state.
In essence, GitOps leverages Git as the single source of truth and ensures that the state of the system in production always matches the declared state in Git.
Flux is a GitOps agent that continuously monitors Git repositories looking for new changes that it can automatically deploy to production. Flux continuously reconciles the state in production to the declared state in Git. Flux manages Kubernetes clusters in production based on the configuration declared in Git in the form of YAML files. Since Flux creates Kubernetes clusters, it builds on top of the core Kubernetes features adding support for tenancy management.
Flux leverages Kustomize, which is a configuration management tool for Kubernetes. Kustomize similarly takes a declarative approach to Kubernetes configuration. Flux leverages a Kustomization controller that manages multiple Kustomization instances.
Figure: Basic cross namespace tenancy using Flux
In the example above, each app exists in its own namespace. In this case, there is no tenancy. Kustomization creates all objects in the namespace in what’s called a ‘cross namespace’ model.
Going further, you can extend this model to include tenancy where Flux uses the Kustomization controller to create multiple objects within a namespace as shown below.
Figure: DIY tenancy with Flux & Kustomization
In this case, each namespace has its own Kustomization instance. In the DIY approach to tenancy you would use the Flux CLI to manually call each YAML file that has the declared configuration for each tenant.
Once deployed, a user with access to namespace A alone, for example, would not be able to make changes to namespace B. Flux along with Kustomization enforces clear boundaries between namespaces.
John Tucker has written about the details of implementing multitenancy with Flux and Kustomize. This is a great read if you’d like to dive into this topic even more.
The key thing to know about this DIY approach is that it involves numerous steps, and is a very manual process. This is counterproductive, and would end up being a distraction from the business’ core activities. Further, it’s hard to navigate through the configuration for each tenant to know what permissions each tenant has. Managing these permissions can become a nightmare at large scale.
Instead, what’s needed is an equally robust, but easier alternative. That’s what we’ve built with Weave GitOps Workspaces.
Introducing Weave GitOps Workspaces
Weave GitOps is an end-to-end GitOps solution that combines the best of open source tooling and software delivery practices into a single unified package. It includes key tools to enable tenancy such as Flux, Kustomize, and more. Recently, Weave GitOps has released a new Workspaces feature that enables tenancy management for Kubernetes clusters at scale. In Weave GitOps a workspace is a tenant.
Weave GitOps allows platform operators to create all workspaces using one or more YAML files. All it takes is a single CLI command to generate all necessary YAML configuration files. These files include the list of policies that apply to each workspace and the list of repositories to which each workspace has access.
Once deployed, you can view all workspace configuration in a single YAML file as below:
tenants: - name:superdevs namespaces: - superdevs - test allowedRepositories: - kind: GitRepository url: https://github.com/superdevs/p... allowedClusters: - kubeConfig: demo-00-kubeconfig teamRBAC: groupNames: - my-team@acme.com rules: - apiGroups: [""] resources: ["secrets", "pods"] verbs: ["get", "list"] -apiGroups: ["apps"] resources: [ "deployments", "replicasets" ] verbs: ["get", "list"] -apiGroups: ["kustomize.toolkit.fluxcd.io"] resources: ["kustomizations"]
You can view an example of this tenant file in our docs. This makes it easy to view all information related to a workspace in context at a glance. Weave GitOps links all fields automatically so you never need to remember which field relates to which workspace. This makes tenancy management much easier and brings you greater control over the process even at scale.
There are a lot of objects that need to be created and linked together such as namespaces, roles, rolebindings, service accounts, and policies. Weave GitOps workspaces enables platform operators to enforce three types of policies on workspaces.
- allowed_application_deploy: This policy determines which Helm release and Kustomization can be used in a tenant.
- allowed_repositories: This policy will verify for all resource types bucket, Git repository, Helm repository, or OCI repository are allowed to be synced to the cluster.
- allowed-clusters: This policy will control which clusters are allowed to target from the hub/management cluster by a particular team.
It is easy to make small mistakes that can make your tenants vulnerable. Weave GitOps workspaces does all of that hard work for you eliminating human errors. In addition, you can tie identity and access management to these workspaces enabling a seamless experience with what they can see and do in the Weave GitOps Dashboard.
Figure: The various uses of tenancy & how they can be expressed with Kustomization, Helm, or Terraform
The image above shows all the ways you can use tenancy with Workspaces. Apart from Kustomize, you could use Helm charts, and Terraform files to further define different parts of your infrastructure. Weave GitOps natively integrates with these tools giving you a seamless experience as a Platform Operator.
Figure: Weave GitOps Workspaces introduces policy checks for end-to-end compliance with tenancy
As the image above shows, the policy checks are implemented based on the Kustomize instances and are applied at every step of the pipeline from commit, to deploy, to runtime. These policy checks ensure that security is baked into the software delivery process by default. At WeaveWorks, we call this ‘Trusted delivery’ - the process of managing security by using policy as code - in the case of Workspaces, we apply this idea to tenancy.
To take things a step further, Weave GitOps Enterprise builds on these already-powerful capabilities and makes it even easier to manage tenancy. Weave GitOps Enterprise renders all tenant configuration in a UI that is easy to view and navigate no matter how many tenants you manage. Further, Weave GitOps Enterprise adds the ability to setup custom notifications so you get an alert whenever a tenant is violated. This means that if a user attempts to take some action in a namespace that they do not have permission to, the system not only prevents this, but also notifies you of the suspicious activity immediately. This is vital information to protect against threats from outside, and accidents from within.
Benefits for the Operator Weave GitOps
Workspaces enables platform operators to isolate app developers and what they are allowed to do or not do on clusters. It provides a simple way to organize your engineering teams and manage their access to resources (RBAC). You can easily define the boundaries/perimeter for many teams of developers. By implementing policy checks and notification, Weave GitOps Workspaces gives the platform operator greater control and visibility into activities across all tenants.
Benefits for the Developer
For application developers, Weave GitOps Workspaces allows them to access clutter-free tenants with only the resources that are relevant to them. These tenants can be accessed by developers on a self-service basis without requiring manual setup from a platform operator. This helps with developer productivity. Further, as developers are restricted from taking actions that may affect the performance of other tenants and vice versa, there is a higher level of confidence that security guardrails are built-in. Developers can double down on what they do best - write code - and leave the tenant management to platform operators.
Conclusion
Tenancy is table stakes for teams that operate in the cloud-native world of Kubernetes. While Kubernetes allows for tenancy in its architecture, its capabilities are limited. Flux, based on the GitOps approach, has a more mature and powerful approach to tenancy management. Weave GitOps takes the best of Kubernetes, Flux, Kustomize, and a host of other tools and brings them together in an elegant, end-to-end solution that we call Workspaces. As you look to manage tenancy for numerous software delivery teams in your organization, you need a robust tenancy management tool. Weave GitOps Workspaces is all you need to manage tenancy at scale. If you’re an existing user, reach out to us to learn more about Workspaces. If you’re new to Weave GitOps, download Weave GitOps Core and get started in your GitOps journey.
Whitepaper: How GitOps Enables A Continuous Application Lifecycle
Discover what you need to start building a GitOps pipeline today.
