[Feature Request] - Gitlab Provider: ability to add custom ca pem file for validation tls.

[aboe76]

Describe the solution you'd like

Gitlab provider secretstore should be able to use a custom tls certificate from a private CA

What is the added value?

Some customers use a gitlab self hosted instance with private CA. The current crd doesn't give this option to validate the certificate.

Give us examples of the outcome

spec:
  provider:
    # provider type: gitlab
    gitlab:
      url: https://gitlab.example.com <<<< custom https tls from private CA
      privateCA:
        type: "Secret"
        name: tls-ca
        key: "cacerts.pem". <<< private ca-cert pem
      auth:

Observations (Constraints, Context, etc):

kubernetes version: v1.22.7+k3s1 external secrets version: 0.5.6

log:

{"level":"error","ts":1654164267.811398,"logger":"controller.secretstore","msg":"Reconciler error","reconciler group":"external-secrets.io","reconciler kind":"SecretStore","name":"gitlab-dev-secret-store","namespace":"default","error":"could not validate provider: could not verify if the client is valid: Get \"https://<REDACTED>/api/v4/projects/803/variables\": x509: certificate signed by unknown authority","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/home/runner/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:266\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\t/home/runner/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:227"}

[gusfcarvalho]

Hi @aboe76 ! One thing you can do is mount the certs as a volume into external-secrets pod.

[djcass44]

Hi @gusfcarvalho, the Operator/Helm chart does not offer a way to mount volumes. I've opened #1286 to add it

[alesz]

Any luck with volume mount approach? I have tried with additional volume mount override on /etc/ssl/certs/ca-certificates.crt, also explicitly setting SSL_CERT_FILE path variable to no avail. OperatorConfig successfully updates Deployment, but it seems to be ignored in runtime. Using external secrets v0.5.7

[alesz]

Never mind, confirming /etc/ssl/certs/ca-certificates.crt is used correctly, caused by incomplete certificate chain on Gitlab serving instance

[djcass44]

I can confirm that mounting the volumes to any location and setting SSL_CERT_FILE works.

The below example (the secret name and mount path are arbitrary) should be all you need if for whatever reason you can't override the default ca-certificates.crt file.

extraVolumes:
  - name: certs
    secret:
      secretName: my-corp-ca
extraVolumeMounts:
  - name: certs
    mountPath: /var/run/secrets/corp.internal/ca
    readOnly: true
extraEnvs:
  - name: SSL_CERT_FILE
    value: /var/run/secrets/corp.internal/ca/ca.crt

[rnrsr]

yea can use the extraVolume and extraMount like:

extraVolumes:
  - name: certificate-authority
    secret:
      secretName: my-vault-ca
      optional: false

extraVolumeMounts:
  - name: certificate-authority
    mountPath: /usr/local/share/ca-certificates
    readOnly: true

From man update-ca-certificates FILES section:

/usr/local/share/ca-certificates Directory of local CA certificates (with .crt extension).

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 30 days with no activity.

[lknite]

I was able to get this to work with the following: (using a secret w/ key 'ca.crt' which has the base64 encoded certificate)

external-secrets:

  extraVolumeMounts:
  - mountPath: "/etc/ssl/certs"
    name: ca-bundle
  extraVolumes:
  - name: ca-bundle
    secret:
      secretName: ca-bundle

What's important about this is, though we've all got this working using extra volume mounts, we solved it in several different ways cause we don't know the inner-workings. This is why its easier if this ability is provided via the helm chart ... let's us get this use case working faster without having to reinvent.

All enterprise implementations will have to reinvent this ... not too big a deal, cause we've done it a million times, but always nice when its in the helm chart cause what if our solution stopped working at some point ... if its in the helm chart we can expect it to keep working even if the location changes.

[nathanielkeeler]

For users of the Openshift Operator of External-Secrets, the solution is to add the extraVolumeMounts and the extraVolumes, as described above, into the OperatorConfig-Ressource.

apiVersion: operator.external-secrets.io/v1alpha1
kind: OperatorConfig
metadata:
  name: cluster
spec:
  # ...other values
  extraVolumes:
    - name: ca-bundle
      secret:
        secretName: ca-bundle
  extraVolumeMounts:
  - mountPath: "/etc/ssl/certs"
    name: ca-bundle