UNCLASSIFIED - NO CUI

Improve out-of-the-box support for connecting to external SSO endpoint

The current chart does not natively support a number of elements required to successfully integrate NeuVector with a private SSO endpoint.

  1. Creation of a Secret holding the certificate for the CA that signed the OIDC
  2. Even with a SSO CA secret available, the chart does not natively expose any way to have NeuVector trust the certificate.
  3. The out-of-the-box Network Policies do not support enabling egress to the SSO endpoint

1. Creation of a Secret holding the certificate for the CA that signed the OIDC

This is actually a gap in the Big Bang helm chart, but I'll mention this here as it is closely related.

When .ValuesSSO.certificateAuthority is defined in the Big Bang helm chart, A tls-ca-sso Secret is created in the namespaces of each of the following core/addon applications: anchore, argocd, elasticsearch-kibana, gitlab, grafana, jaeger, kiali, mattermost, monitoring, nexus-repository-manager & sonarqube

But an equivalent secret is not currently created in the NeuVector namespace, and needs to be (manually) created outside of the Big Bang framework.

Note: The comments in the Big Bang values file indicate that populating .ValuesSSO.certificateAuthority will result in a secret being created in "each namespace", but after digging a bit deeper I've confirmation that this is only true for additional applications defined under .Values.packages. Possibly this functionality could be extended to the core & addon applications?

# -- Global SSO values used for BigBang deployments when sso is enabled
sso:
  # -- Certificate authority for the identity provider's certificates
  certificateAuthority:
    # -- The certificate authority public certificate in .pem format.  Populating this will create a secret in each namespace that enables SSO.
    cert: "" # See docs/assets/configs/example/dev-sso-values.yaml for an example

See:

2. Even with a SSO CA secret available, the chart does not natively expose any way to have NeuVector trust the certificate

I've managed to mount the Secret to the appropriate location in the neuvector-controller-pod pod(s) by defining the below postRenderers, but ideally this could be supported out-of-the-box by the Helm chart.

neuvector:
  postRenderers:
    - kustomize:
        patchesStrategicMerge:
          - apiVersion: apps/v1
            kind: Deployment
            metadata:
              name: neuvector-controller-pod
              namespace: neuvector
            spec:
              template:
                spec:
                  containers:
                  - name: neuvector-controller-pod
                    volumeMounts:
                    - mountPath: /etc/ssl/certs
                      name: tls-ca-sso
                      readOnly: true
                  volumes:
                  - name: tls-ca-sso
                    projected:
                      defaultMode: 420
                      sources:
                      - secret:
                          name: tls-ca-sso
                          optional: true

3. The out-of-the-box Network Policies do not support enabling egress to the SSO endpoint

Other charts have enabled this connectivity by either:

  • Including a specific SSO NetworkPolicy (eg. GitLab)
  • Having a existing egress policy that happens to also allow connectivity to the SSO endpoint (eg. Anchore)
  • Providing the ability to define custom additional Network Policies. Eg.

NOTE: I'm aware that the ability to define custom Network Policies for GitLab Runner is not related to SSO endpoint egress, but a similar capability would be beneficial for NeuVector. Not only is an additional NetworkPolicy required between NeuVector → SSO, but potentially NeuVector → Container Registry, NeuVector (remote cluster) → NeuVector (primary cluster) (See. multi-cluster management/federation), etc.

Again, the wrapper helm chart exposes this capability for additional applications defined under .Values.packages, but unfortunately this capability hasn't been extended to the core & addon applications.

Edited by Jason Carlton