Today we're announcing the release of OpenUnison 1.0.21. Most of the updates are "under the covers" but there are a few enhancements that are exciting if you want to better manage your clusters without having to manually run kubectl every time someone opens a ticket!

Security Enhancements

In addition to our updates of all our libraries and dependencies, 1.0.21 brings an important enhancement to security: support for the Kubernetes TokenRequest API. OpenUnison, like most cloud native applications that interact with Kubernetes, uses a ServiceAccount to authenticate API requests. As we have discussed in past blog posts, these ServiceAccount tokens can be easily abused if not rotated regularly. Since OpenUnison is one of the entry points to our cluster, and can have a privileged ServiceAccount when using our impersonating proxy or management systems, an attacker could get a hold of that token if they were to exploit a bug or vulnerability anywhere between their interface and the API server. To combat this issue, the TokenRequest API was created to generate short lived tokens that can be consumed by workloads in the cluster instead of static ServiceAccount tokens. This means that if an attacker were to get a hold of a token, it's only good for about 10 minutes. It also means the tokens aren't stored in your etcd database. Finally, each Pod get's its own unique identity that can be tracked. So if a token is compromised, you know exactly which Pod it came from! Enabling this feature is very easy, in your vaules.yaml add:

services:
  enable_tokenrequest: true
  token_request_audience: api
  token_request_expiration_seconds: 600

This will update your deployments and ServiceAccount to use the TokenRequest api instead of static ServiceAccount tokens.

Multi Cluster Management

Many of our customers love the fact that they can provide a multi-tenant cluster without having to manually create namespaces or RBAC bindings. In 1.0.21 we extended this to make it easier to work with multiple clusters with a single "management cluster". This means you only need one database to store all your audit and authorization data across your enterprise and can dynamically add clusters via Kubernetes apis or using pre-built helm charts. The best part is we've developed a mechanism for securely communicating with an API server without exposing ServiceAccount tokens!

GitOps

It's the latest craze in Kubernetes. Using git to manage your clusters makes sense. It makes it easier to track changes and provides a workflow outside of Kubernetes for developers to deploy their code and applications. This release gives you the ability to provision objects directly to a git repository instead of creating or patching objects directly against an API server. Add an SSH key to your repository and you're now able to automate the creating of namespaces, RBAC bindings, quatas, and anything else you ma want to automate!

Dynamic Workflows

Starting in 1.0.21, you no longer have to build workflows in XML and build them into your container. Now you can create self service workflows as Kubernetes custom resources. This means you'll be able to change how we design workflows pretty easily to match your own requirements. It's also part of a larger move to make all of OpenUnison's application level configuration options available as Kubernetes custom resources instead of baking them into static configuration files.

We're in the process of re-doing our documentation to make it easier to consume and apply to your own use cases. Much of the documentation for these features are included in that process so stay tuned! Finally, if you want to see the details of the release it's all on github!