Supporting OpenBao as Secrets Store

[eyenx]

In what area(s)?

/area operator

/area docs

Ask your question here

Dapr currently supports HashiCorp Vault as a secrets store provider. I’m interested in contributing to Dapr to add support for OpenBao as a secrets store provider as well.

What would be the steps to begin this effort? I assume the existing HashiCorp Vault provider may already work with an OpenBao backend — I plan to test this. However, my preference would be to introduce a separate openbao provider for clarity and long-term maintainability.

[sicoyle]

@nelson-parente can you pls mv this to components contrib repo?

Hi @eyenx 👋 Thank you for you interest in contributing to Dapr!

Yes, please check if OpenBao would work with the existing HashiCorp Vault component.

• If it does not, then this will include a new directory and changes in components contrib repo here: https://github.com/dapr/components-contrib. You'd have to include a new openbao directory somewhere under the secretstore providers here: https://github.com/dapr/components-contrib/tree/main/secretstores. You can reference the other components and implement the interface required for secretstores to work with runtime with an openbao.go file (with a corresponding test file(s)), in addition to the metadata.yaml file denoting the component manifest. A docs issue would be required, in addition to be written hopefully by you alongside these contributions.

• If OpenBao does work with HashiCorp Vault provider, then I would ask that you please document this in the dapr/docs repo.

Here are the components contrib contrib contributing guidelines: https://github.com/dapr/components-contrib/blob/main/CONTRIBUTING.md

Lmk if you have additional questions!

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

[eyenx]

Thanks @sicoyle

The first step will to look if it works with the Vault provider and add that to the docs (pretty sure it does)

Anyhow on the long run we would like to provide our own provider as the API will diverge at some point too much to be able to still use the same provider.

Thanks for the info and tips, I will look into trying it out this month!

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

[eyenx]

Hi @sicoyle

The Vault Provider just works with Openbao

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: openbao
spec:
  type: secretstores.hashicorp.vault
  version: v1
  metadata:
    - name: vaultAddr
      value: http://openbao.openbao.svc.cluster.local:8200
    - name: skipVerify # Optional. Default: false
      value: true
    - name: vaultToken
      secretKeyRef:
        name: mytoken
        key: token
    - name: enginePath # Optional. default: "secret"
      value: "secrets"
    - name: vaultValueType # Optional. default: "map"
      value: "map"

I was able to grab the secret over DAPR w/o issues.

I will go along and add this to the documentation.

Can you point me towards the right place to put this in?

I just re-read your message. I will take a look thanks!

[pree]

This is really cool! Even though the Vault component works fine (for now) I would be in favor of adding OpenBao as it's own component, this would give us the flexibility to add new features, which are only supported using OpenBao.
Additionally it allows for maintainability and a clear upgrade path for integrations already using OpenBao.

[eyenx]

I added a Draft PR

dapr/docs#4917