ADR for managed OpenBao on AppCat

[ioboi]

Summary

Checklist

• Try to isolate changes into separate PRs (to build a better changelog).
• Categorize the PR by setting a good title and adding one of the labels:
  change, decision, requirement/quality, requirement/functional, dependency
  as they show up in the changelog
• Link this PR to related issues if applicable.

[Kidswiss]

Sounds reasonable.

Using the integrated raft storage makes things a lot less complex than using an external database.

[mdnix]

Thanks for submitting this ADR @ioboi!

Overall I like it and I think using the Helm chart here makes total sense as it fits in well with the AppCat framework. While doing my own research on this I also leaned heavily towards this approach.

Just a few things to help me understand:

1. How will auto-unseal be configured effectively?
2. Regarding the authentication method stated in the document, is the kubernetes authentication method also required for ServiceAccounts to consume Secrets from the secrets engine?
3. At the top of the document it states that it will be used for PKI and secrets management. In that case I assume both engines will be configured by default?

[ioboi]

Thanks for submitting this ADR @ioboi!

Overall I like it and I think using the Helm chart here makes total sense as it fits in well with the AppCat framework. While doing my own research on this I also leaned heavily towards this approach.

Just a few things to help me understand:

1. How will auto-unseal be configured effectively?
2. Regarding the authentication method stated in the document, is the kubernetes authentication method also required for ServiceAccounts to consume Secrets from the secrets engine?
3. At the top of the document it states that it will be used for PKI and secrets management. In that case I assume both engines will be configured by default?

@mdnix thank you for the review ☺️

1. We will propose a solution in this PR in the next week.
2. This depends on the integration. For example the Agent injector needs access to the Kubernetes API but the External Secrets Operator supports a multitude of methods.
3. This is a remainder of an earlier version. I think by default at least a KV2 could be configured. I only saw, that the use of the PKI engine was discussed in ADR24. We will update the ADR to be more specific.

[Kidswiss]

Thanks for submitting this ADR @ioboi!
Overall I like it and I think using the Helm chart here makes total sense as it fits in well with the AppCat framework. While doing my own research on this I also leaned heavily towards this approach.
Just a few things to help me understand:

1. How will auto-unseal be configured effectively?
2. Regarding the authentication method stated in the document, is the kubernetes authentication method also required for ServiceAccounts to consume Secrets from the secrets engine?
3. At the top of the document it states that it will be used for PKI and secrets management. In that case I assume both engines will be configured by default?

@mdnix thank you for the review ☺️

1. We will propose a solution in this PR in the next week.

2. This depends on the integration. For example [the Agent injector](https://developer.hashicorp.com/vault/docs/deploy/kubernetes/injector/examples) needs access to the Kubernetes API but the [External Secrets Operator](https://external-secrets.io/latest/provider/hashicorp-vault/) supports a multitude of methods.

3. This is a remainder of an earlier version. I think by default at least a KV2 could be configured. I only saw, that the use of the PKI engine was discussed in ADR24. We will update the ADR to be more specific.

About the k8s integration: it probably warrants its own ADR. If we actually want to add it to the service offering in the first place.

[ioboi]

Hey @Kidswiss, @mdnix

I updated the ADR with an example CRD definition. The unsealing should be much clearer now. Happy to get feedback 😄

[ioboi]

@Kidswiss rebased and ready to be merged 🎉