tremolosecurity/openunison-k8s-operator-converter

Convert OpenUnison to Run on the OpenUnison Operator

First, deploy the OpenUnison Operator into your openunison namespace - https://github.com/TremoloSecurity/openunison-k8s-operator#kubernetes-and-openshift-3x

Next, create a ConfigMap that will store a list of secrets and whether or not the converter should run in "Dry Run" mode. Its recommended to run first in dry run mode to inspect the OpenUnison custom resource that is generated and see what actions the converter will take.

kubectl create configmap converter-map --from-literal=DRY_RUN=true --from-literal=KEEP_SECRET=unisonKeystorePassword,K8S_DB_SECRET,AD_BIND_PASSWORD,SMTP_PASSWORD,REG_CRED_PASSWORD,OU_JDBC_PASSWORD -n openunison

NOTE The KEEP_SECRET lists the values from ou.env that should remain in a secret as opposed to be tracked directly in the custom resource. The above is the default list but if you added any more you should make sure to adjust.

Now launch the conversion Job:

kubectl create -f https://raw.githubusercontent.com/TremoloSecurity/openunison-k8s-operator-converter/master/src/main/yaml/openunison-operator-converter-job.yaml -n openunison

A pod will be created that will output the results of the change along with resulting custom resource. Verify that it is accurate. Pay special attention to make sure that no secret information made it into the custom resource.

Once you are happy with the custom resource, change the DRY_RUN field in the converter-map ConfigMap to "false" and re-run the Job (NOTE This is NOT a zero down time operation):

kubectl delete -f https://raw.githubusercontent.com/TremoloSecurity/openunison-k8s-operator-converter/master/src/main/yaml/openunison-operator-converter-job.yaml -n openunison

kubectl create -f https://raw.githubusercontent.com/TremoloSecurity/openunison-k8s-operator-converter/master/src/main/yaml/openunison-operator-converter-job.yaml -n openunison

The existing Deployment objects are scaled to 0, the ingress object is backed up and deleted and the custom resource is generated and deployed. Once the pods have settled (usually doesn't take more then a couple of minutes) go ahead and login.

Rolling Back

If you need to rollback:

1. Delete the Ingress object and create a new one from the backup ConfigMap
2. Scale the -orchestra Deployment objects to 0
3. Scale the original Deployment objects to 1 (or whatever is needed)

Deleting Old Objects

Once you are happy with the operator based management of OpenUnison delete the objects:

kubectl delete service openunison -n openunison
kubectl delete deployment openunison
kubectl delete deployment amq
kubectl delete serviceaccount openunison

Permissions for Service Accounts

The Deployment generated by the operator runs as openunison-orchestra instead of openunison. If you customized what OpenUnison has access to you'll need to udpate the RBAC RoleBinding objects. If using the Orchestra Automation Portal update the openunison-cluster-administrators ClusterRoleBinding with the openunison-orchestra ServiceAccount.