Openstack Barbican KMS support

[poikilotherm]

Hello there!

Would there be interest in upstreaming 3d67bf1f4b14ec8f19c38c5481a32a016ab44357 (coming from https://github.com/getsops/sops/compare/main...clelange:sops:master)?

As an Openstack user, I would greatly benefit from using SOPS with Barbican in FluxCD.

Cheers!

(Tagging @clelange and @rochaporto, as they are the original authors)

[clelange]

@rochaporto had created https://github.com/getsops/sops/pull/683 back then, but what was missing (and still is) in this comment:

1. There is a sizeable enough portion of our user base that would like this
2. We can work out a detailed testing guide within this PR
3. There is full coverage integration tests that can be ran locally and in CI within this PR

I think from our side (CERN community), we've found other solutions, but I agree that in general this would still be useful to have.

[rochaporto]

From my side we've moved away from this solution long ago. There are still people using sops but with a vault backend. But most are using vault directly, with secret retrieval at deployment time with plugins for templating.

[BeyondEvil]

From my side we've moved away from this solution long ago. There are still people using sops but with a vault backend. But most are using vault directly, with secret retrieval at deployment time with plugins for templating.

Mind going into some more detail on your solution?

We're building a multi-cloud (different providers due to regulations) k8s cluster setup, and want a solution that is as cloud provider agnostic as possible.

[rochaporto]

From my side we've moved away from this solution long ago. There are still people using sops but with a vault backend. But most are using vault directly, with secret retrieval at deployment time with plugins for templating.

Mind going into some more detail on your solution?

We're building a multi-cloud (different providers due to regulations) k8s cluster setup, and want a solution that is as cloud provider agnostic as possible.

Sure. We're relying on a central ArgoCD deployment with a plugin hooking to the argocd-vault-plugin (https://argocd-vault-plugin.readthedocs.io/en/stable/howitworks/), the config is something like:

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: argocd
  name: vault-cmp
data:
  avp-helm.yaml: |
    apiVersion: argoproj.io/v1alpha1
    kind: ConfigManagementPlugin
    metadata:
      namespace: argocd
      name: argocd-vault-plugin-helm
    spec:
      init:
        command:
        - "sh"
        - "-c"
        - "helm dependency update"
      allowConcurrency: true
      discover:
        find:
          command:
            - "sh"
            - "-c"
            - "find . -name 'Chart.yaml' && find . -name 'values.yaml'"
      generate:
        command:
          - "sh"
          - "-c"
          - "helm template $ARGOCD_APP_NAME --include-crds -n $ARGOCD_APP_NAMESPACE ${ARGOCD_ENV_HELM_ARGS} . | argocd-vault-plugin generate - "
      lockRepo: false

The placeholders in the app values.yaml then look like:

<path:kv/data/path/to/some/item#itemname>

We have a similar plugin for kustomize, just running kustomize build instead of helm template.

The main difference to SOPS is that the secrets are not committed so not part of the versioned app state, and added when doing reconciliation/sync.