TL;DR

• Operator 2.0 supports Ingress annotations and more Deployment configuration options
• Deployment Helm Chart creates NetworkPolicy objects and can be used for long term management
• Portals support SSO with the dashboard through both OpenID Connect and SAML2 transparently

Today we're proud to announce new versions of the OpenUnison operator, updates to the helm charts. and some updates to the Orchestra login portals. In this post we'll detail the updates each of these systems.

OpenUnison Operator 2.0

The new version of the OpenUnison Operator adds several features that have been requested by users. Where previously many operational updates had to be made to objects generated by the operator after creation, those updates can now be managed through the operator. First, in addition to setting host names for the Ingress object created by the operator you can now set annotations and the type. This makes it easier to incorporate tools like LetsEncrypt directly into your openunison object without having to maintain or update the Ingress object directly after deployment. An example would be added to the host section:

  hosts:
  - annotations:
    - name: kubernetes.io/ingress.class
      value: nginx
    ingress_name: openunison
    ingress_type: nginx

In this snippet the openunison object defines that the ingress type is nginx. Right now this is the only supported Ingress type but stay turned for automated Istio and Trafek support coming soon! We also define multiple annotations that are added to the Ingress object. Updating this list of annotations will result in the Ingress object being updated.

In addition to Ingress updates, the operator now supports several Deployment level configuration options such as setting requests and limits, node selectors, and custom readiness and liveness probes. You can also specify our own pull secret from the openunison object too! Here's an example:

  deployment_data:
    liveness_probe_command:
    - /usr/local/openunison/bin/check_alive.py
    node_selectors:
    - name: kubernetes.io/hostname
      value: k8s-istio-kiali2
    pull_secret: ""
    readiness_probe_command:
    - /usr/local/openunison/bin/check_alive.py
    - https://127.0.0.1:8443/auth/idp/k8sIdp/.well-known/openid-configuration
    - issuer
    tokenrequest_api:
      audience: api
      enabled: false
      expirationSeconds: 600

Finally, the helm chart that deploys the openunison operator now supports the CustomResourceDefinition v1 api for any cluster running at 1.16 and above. Older clusters will still deploy with the v1beta1 api. To upgrade:

1. Backup your OpenUnison objects
2. Upgrade your helm repository
3. Upgrade your helm deployment

Helm Chart Updates

The helm charts for the login portals add several key new features. First, the charts now can generate NetworkPolicy objects to help lock down network access to the OpenUnison pods. Especially when using impersonation, the OpenUnison ServiceAccount can be thought of as "privileged", so it's important to minimize access from inside of the cluster to your Ingress controller and your Prometheus implementation. Blocking access at the network layer to pods in your cluster adds an important additional layer of security. The policies are based on Namespace labels, so you'll need to make sure that your namespaces are properly labeled. Here's an example of the new network policy configuration in the helm chart values.yaml:

network_policies:
  enabled: true
  ingress:
    enabled: true
    labels:
      app.kubernetes.io/name: ingress-nginx
  monitoring:
    enabled: true
    labels:
      app.kubernetes.io/name: monitoring
  apiserver:
    enabled: false
    labels:
      app.kubernetes.io/name: kube-system

In this configuration policies are created to allow access from both the Ingress namespace and the monitoring namespace.

We also made multiple updates to make it easier to use the Helm chart as a long term management tool instead of just an initial deployment system. The new Ingress annotations and Deployment configuration options are available as configuration options in the charts. We also added the ability to name additional keys from the source Secret that can be imported and non-secret name/value pairs that can be added to the openunison object. This will make it much easier to use Helm as a configuration management tool in addition to a deployment tool.

Portal Image Updates

The Orchestra login portals all have a few new features to make deployment and management easier. A common issue we see is that while kubectl access works, the dashboard will fail to load. This is because the dashboard reverse proxy can't complete the OpenID Connect SSO process with the login portal. This SSO process requires that OpenUnison be able to talk to it's self through the Ingress controller to properly generate the tokens needed to satisfy OpenID Connect and can create issues where load balancers or DNS is not configured to support access through the Ingress between pods. This most often happens in cloud environments. To handle this issue, OpenUnison now supports both OpenID Connect and SAML2 for logging into the dashboard. By adding K8S_DB_SSO as "saml2" to your Helm chart:

openunison:
  replicas: 1
  non_secret_data:
    K8S_DB_SSO: oidc
  secrets: []

OpenUnison will instead use SAML2 between the dashboard and the OpenUnison portal. SAML2 doesn't require the connection between pods and eliminates the problem of OpenUnison not being able to connect to it's self through the Ingress.

Learn more about how OpenUnison can simplify your Kubernetes security!