We've created a new option for deploying OpenUnison: the ouctl command! This command simplifies the deployment of OpenUnison by automating the creation of Secrets and deploying helm charts. We've cut down the number of steps to deploy OpenUnison from:

‍

$ kubectl create -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: orchestra-secrets-source
  namespace: openunison
type: Opaque
data:
  K8S_DB_SECRET: Znp6dmhJUUNSS3M5bWxpRXB0ZDR6OHNnNmpCQ2dHSE9NWHpmZ2M4VXo4andhcFNsT05xcFd0SXZWU0VHR2ozRg==
  OIDC_CLIENT_SECRET: dWtDbUEwRFdoeU9Dd3BYdDd3bFc0clZyemZHQXltdkFjbWVRa21uSlJsa0FqZlZBQUJvRTJldHl4dDdhY3lhUA==
  unisonKeystorePassword: clZ1UHZXYkl0cEV5WFBYY1hmbXBzMGswZUdUbTFZUjRrS2hrcFRZN1A5TmVQQ2JLMnJoTUhzdWtFc2xuRUZpWA==
EOF
$ kubectl create ns openunison
$ helm install openunison tremolo/openunison-operator --namespace openunison
$ while [[ $(kubectl get pods -l app=openunison-operator -n openunison -o 'jsonpath={..status.conditions[?(@.type=="Ready")].status}') != "True" ]]; do echo "waiting for operator pod" && sleep 1; done
$ helm install orchestra tremolo/orchestra --namespace openunison -f /path/to/values.yaml
$ while [[ $(kubectl get pods -l app=openunison-orchestra -n openunison -o 'jsonpath={..status.conditions[?(@.type=="Ready")].status}') != "True" ]]; do echo "waiting for pod" && sleep 1; done
$ helm install orchestra-login-portal tremolo/orchestra-login-portal --namespace openunison -f /path/to/values.yaml

To:

$ ./ouctl install-auth-portal -s /path/to/secret/data /path/to/values.yaml

OpenUnison is still using the same helm charts, but the ouctl command manages their creation. It also creates the orchestra-secrets-source Secret for you as well, so there's no issues with getting the correct client secret, mis-encoding, or getting an extra carriage return in the value. It also takes the guess work from determining when to run the charts. In this video, we go from an empty cluster to authenticating with Okta in a just a few minutes!

What's even more exciting about the new ouctl command is that it automates the onboarding of new clusters into a multi-cluster environment!

Multi-Cluster SSO

Onboarding a new cluster into a multi-cluster environment can be painful. Depending on how you plan to authenticate, you'll need to integrate your cluster with your identity provider of choice. Even with the simplicity of OpenUnison, this means getting a new client secret, establishing a trust, and verifying the connection. Depending on who owns access to your identity provider, this can be a painful process to repeat or automate.

The ouctl utility solves this issue by converting one of your Kubernetes clusters into a control plane, with access to the rest of your clusters centralized into that control plane. This means that, as a cluster owner, you control access to all your clusters and their onboarding.

Running a central control plane cluster does have a risk of creating a single point of failure, but you can mitigate that risk by making sure the control plane is highly available by running multiple OpenUnison Pods, running multiple Ingress controllers and making sure there's a load balancer for those controllers. If you're running a multi-cluster environment, these are the types of steps you would take anyways!

Deploying a satellite cluster is pretty simple:

1. Create a values.yaml, but without the oidc section
2. Download the root credentials for your new satellite
3. Get credentials for your control plane cluster

Finally, run the ouctl command:

$ ./ouctl ./ouctl install-satelite /path/to/openunison-satelite-1.yaml openunison-controlplane kubernetes-admin@kubernetes

No client secrets, no certificates. The ouctl command will:

1. Create an identity provider in the control plane cluster
2. Generate the correct oidc section of your satellite's values.yaml
3. Find the right certificate in your control plane for your satellite to make sure it can securely communicate with the control plane
4. Deploy OpenUnison to the satellite cluster
5. Create "badges" in the portal for the new satellite cluster's tokens and dashboard

Once done, when you login you're OpenUnison Portal will have new badges:

When you configure your values.yaml, you can limit who can get access to these badges based on groups from your identity provider. This simplifies management of access into your clusters in several ways:

1. You're not reliant on an external group to setup SSO for your cluster
2. You can automate onboarding of new clusters without having to rely on an external API
3. Changes from your identity provider only need to be made once

To show how quickly you can onboard a new satellite, here's an approximately 10 minute video showing the process:

Given that this utility is small enough to fit on an easy to deploy container, the ouctl utility can be run from a Job to automate the onboarding even more!

Kubernetes, AND BEYOND!

Once you've onboarded your clusters, you can use OpenUnison to manage access to your cluster management systems too. Whether you're integrating with ArgoCD, Prometheus, or any other application that can leverage an external identity system for authentication you can use OpenUnison to manage access and provide a central portal for access to those systems. If you're looking for answers or need some help, you can open an issue on GitHub and we'll be happy to help. If you're interested in a commercial support contract, take a look at our pricing and reach out!