A Kubernetes Controller for Styra DAS
We just open sourced our Kubernetes controller for the Styra Declarative Authorization Service (DAS). If you are interested in managing OPAs via Styra DAS via Kubernetes, read on.
What is Styra Declarative Authorization Service?
Styra DAS is a control plane to manage many OPA instances on the ground. Similar as what Istio is to Envoy, or the Kubernetes control plane to Kubelets. It tells those downstream instances what they should do (and reports back status, decisions, analytics, etc).
You can connect many OPA instances for different use cases
Use cases for fine-grained access control
I’m sure there are plenty use-cases for controlling access to resources. This is a short list of the prominent ones:
1. OPA as a Kubernetes Admission Controller to audit and decide on Kubernetes API requests, which provides a more fine-grained solution to standard Kubernetes RBAC.
2. OPA on the network, to take decisions on whether someone is allowed to access a resource on the network. This usually comes in pair with envoy, via the ext_authz filter.
3. Another prominent use-case is from inside a business application, for example to check if someone is allowed to request certain data from the database.
In any case, there are a lot of OPA instances to manage.
In Styra DAS, each real-world software system that you’re using OPA to control is represented by a system. A single system therefore manages possibly many different OPAs, all of which are enforcing the same policies. For example, if you want to use OPA to enforce policy on three Kubernetes clusters, you’ll create 3 different systems. If you also want to use OPA to enforce policy on four different envoy-based service meshes, you will create four additional systems. To register an instance in Styra DAS, one needs to create a system at the DAS API, retrieve the registration token and configure the actual OPA instance with the token
We can do that manually via UI, or we can automate it.
Provider-styra helps to automate the management of OPA instances at Styra DAS
Provider-styra is a Kubernetes controller which mirrors the Styra DAS API into the Kubernetes Resources Model. Instead of managing the lifecycle of Styra DAS systems (which represent OPA instances) via their UI or a custom API implementation, we can do so in a standardized way via the Kubernetes API.
YAML representation of a Styra DAS system and the OPA token which is synced back
Why manage Styra DAS systems in Kubernetes?
Well first of all it is nice to have a declarative representation of infrastructure. But there are other benefits.
Folks are already managing applications via Kubernetes and with the acceptance of CRDs as an extension mechanism we are seeing it being extended to other parts as well. Popular examples are the open source project crossplane or proprietary services like Google Config Connector, which allow you to declaratively describe infrastructure in the Kubernetes Resource Model (instead of Terraform HCI, CloudFormation, …).
Some advantages are to re-use the existing machinery for managing yaml in CI/CD pipelines. Make use of Kubernetes RBAC to control access to the API. Or GitOps for infrastructure. Or benefit from other features of the Kubernetes API like mutating and validating webhooks, possibly for more finegrained access control (enabled by OPA btw).
Last but not least we can create higher level APIs with crossplane compositions. And this is where the real benefits start to show. More on this further down.
See provider-styra in action
To follow this tutorial, you’ll need a DAS account. At the time of this writing provider-styra implements two objects: systems and stacks. Stacks are another feature that enable you to write global policies that are applied across many different systems (but that’s for another blog post).
Although provider-styra can be used as a stand-alone Kubernetes controller it is much more powerful in combination with crossplane. Let’s see how we can take them for a spin, following the official documentation:
The crossplane cli allows us to install provider packages easily, but it’s not mandatory. You can also install providers via kubectl apply -f (of course you can), but for the sake of simplicity we use the cli to install provider-styra:
After a short while we can see that our Kubernetes cluster is able to manage additional resources:
Now provider-styra needs to be configured to connect to the endpoint of the Styra DAS control plane:
One last thing to do is to configure authentication: Visit https://<STYRA_INSTANCE>/access-control/api-tokens and create a new token which will be used to authenticate provider-styra at the Styra DAS API.
Make sure to grant that token appropriate permissions, e.g. WorkspaceAdministrator (https://<STYRA_INSTANCE>/access-control/permissions/api-tokens).
Now we are all set and able to create systems. The following is an example of an OPA admission controller at Styra DAS:
A new system should show up at Styra DAS:
Besides creating the system, provider-styra also helps you install the OPAs on your k8s cluster to implement k8s admission control. DAS provides installation artifacts for kubectl, kustomize, and helm. Provider-styra reads the asset endpoint and writes the helm chart values back into a Kubernetes secret, which we can use to install OPA into the cluster and register with Styra:
So far we’ve seen how to declaratively control Styra DAS systems from within Kubernetes. Next we’ll finish using Helm to install the OPAs for admission control. Let’s add provider-helm!
Helm chart deployments with provider-helm
Provider-helm is a Kubernetes controller which manages helm charts in any connected Kubernetes cluster. Install provider-helm via crossplane-cli:
Setup an in-cluster providerconfig so that we can deploy charts into the same cluster (note that this uses cluster-admin permission for the sake of simplicity):
Now we can create a Release which automates the installation of the styra agents helm chart:
We now have a deployment of OPA as an admission controller along with the Styra DAS agents. One step closer, but still room for improvement.
Connecting the dots with crossplane compositions
Instead of describing both resources individually (styra system and helm chart deployment), we can wire them up in a composition.
A composition has two parts:
1. XRD (describes how the object should look like, and of which a CRD will be generated)
2. Composition (the actual composition, similar to helm files in templates/)
For this setup we will spin up virtual Kubernetes clusters inside a host Kubernetes cluster. The full setup is described at github: https://github.com/janwillies/virtual-k8s-styra-opa
With those two resources in place, we can create one or many cluster XRCs which are namespaced instances of compositions:
This will result in two Kubernetes cluster being created, both of which have OPAs installed and are represented at Styra DAS:
Et voila, now with just a single Kubernetes resource, we can create a system at Styra and deploy the agents with a custom configuration as well. This is a simple API we can hand out to developer teams.
The platform team can offer a single API for batteries-included Kubernetes cluster which come with a default set of agents (for compliance, security, monitoring, …).
Summary
Managing a lot of OPA instances is challenging. Styra DAS offers a control plane to help with that. Provider-styra is an opensource Kubernetes controller which mirrors the Styra DAS API into the Kubernetes Resource Model. This allows to model Styra DAS systems (and other resources) as YAML representation and enables workflows like GitOps.
The connection tokens for systems are read from the Styra API into Kubernetes Secrets. With provider-helm it is possible to read the connection tokens and fully automate the installation of OPAs which are connected to the Styra DAS control plane.
I hope this was interesting to you. Feel free to leave a comment or get involved at github.com/crossplane-contrib/provider-styra. You can find me at twitter.com/loswillios.
This article originally appeared in the ITNEXT blog on November 16, 2021.
Interested in learning more about Styra DAS and OPA? Request a Styra DAS demo today!