search

external-secrets / bitwarden-sdk-server

This repository contains a simple REST wrapper for the Bitwarden Rust SDK
https://external-secrets.io
Apache License 2.0
7 stars 1 forks source link

Unable to deploy SDK due to lack of documentation. #8

Closed joryirving closed 1 month ago

joryirving commented 1 month ago

Describe the bug When deploying the bitwarden-sdk-server pod, it fails to start, since a secret called bitwarden-tls-certs does not exist.

To Reproduce On the primary external-secrets chart, set the following values:

bitwarden-sdk-server:
  enabled: true

When I do this, I see the pod spin up, however it's looking for a secret called bitwarden-tls-certs. The documents don't reference this at all, aside from a warning that the sdk must be run in https with no instructions on how to set this up. Kubernetes: 1.30.2 ESO: v.0.9.20

Expected behavior I expect the helm chart/deployment to either create the secret it's looking for, or provide docs/instructions on how to generate the secret via cert-manager.

Additional context I found an example here for the ClusterIssuer, and the Certs, but seeing as it's in the hack folder, and not the docs, this isn't immediately apparently.

Additionally, all documentation states to create/deploy ESO into it's own namespace external-secrets, however the dnsNames in the hack directory point at the default namespace.

Skarlso commented 1 month ago

Hello.

The hack folder contains testing certificates and it's mainly used for end to end testing the service.

This is in the readme on this project:

The server MUST run using HTTPS. A recommended way to generate a certificate is to use cert-manager. The certificate can be defined in a Kubernetes secret called bitwarden-tls-certs. This can be overwritten in the helm chart values file.

The certificate will then be required when using external-secrets' Bitwarden provider.

How the certificate is provided is then up to the user really. The ESO ecosystem did not want to enforce or use cert manager as a prerequisite.

p3lim commented 1 month ago

I was also looking into (finally!) setting up external-secrets with Bitwarden Secrets Manager using this provider, and ran into the same confusion as @joryirving. Providing an example certificate generation using cert-manager (as you do in the hack/ directory) would be more than good enough for most situations, as it's providing a self-signed certificate for an internal service nothing else will ever use.

Skarlso commented 1 month ago

Fair point. So what would be better in this case? Once I implement that annotation thing and document that is that okay?

p3lim commented 1 month ago

Yeah that'll probably do it for most people looking to use this provider, but I'm not going to guarantee that it covers all bases. Supporting the CA annotation is just gravy on top. I'm not sure how much of a bad idea it is to get the certificate this way considering the use case - the internal cluster domain can typically only be secured using a custom PKI solution anyways, and using cert-manager for it is most likely the best way to go about it. Even if someone doesn't use cert-manager the example manifest is more than descriptive enough for others to roll their own solution.

Skarlso commented 1 month ago

Going do this ticket together with https://github.com/external-secrets/bitwarden-sdk-server/issues/9

Skarlso commented 1 month ago

@p3lim @joryirving updated the document separately because 9 takes longer... :)