Support the configuration of sensitive data using existing Kubernetes secrets

[rszamszur]

Hello BuildBuddy Team,

I am reaching out to discuss an enhancement proposal for the Helm charts. Currently, these charts require secrets to be provided within the values.yaml file. This approach, while functional, it adds an extra layer of complexity and maintenance overhead. This complexity becomes particularly evident in situations such as:

• When an organization has specific requirements or methods for managing secrets.
• When there are limitations or issues with third-party solutions, for instance: ArgoCD + helm-secrets.
• When applying GitOps practices - ensuring data is encrypted at rest but still accessible by the GitOps controller.

I would like to propose a feature request to enhance the Helm charts to support the use of existing Kubernetes secrets. The ideal implementation of this feature would cater to any sensitive information that can currently be configured through value files.

I am keen to contribute to the development of this feature if it aligns with your project's goals. Could you please share any specific guidelines or requirements for such contributions? I would greatly appreciate any feedback or direction you could provide to help me proceed with this implementation.

For reference, I have included links to example open-source charts that support using existing k8s secrets to some extent:

• Bitnami PostgreSQL Chart
• Coder Helm Chart
• GitHub Actions Runner Controller Chart

Have a good one!

[siggisim]

Hey @rszamszur!

Thanks for the proposal - would specifying our config options as environment variables work for your use-case? https://www.buildbuddy.io/docs/config#environment-variables

You can specify environment variables in your BuildBuddy config.yaml (which maps to the config: block of the helm values.yaml) and then populate those environment variables using whatever secrets management tool you'd like.

For example a bring-your-own-runners values.yaml might look like this:

config:
  executor:
    app_target: "grpcs://remote.buildbuddy.io:443"
    local_cache_size_bytes: 50000000000 # 50GB
    api_key: "${API_KEY}"

And then you can populate the API_KEY environment variable using Kubernetes secrets: https://kubernetes.io/docs/concepts/configuration/secret/#using-a-secret

[rszamszur]

Thanks for the proposal - would specifying our config options as environment variables work for your use-case? https://www.buildbuddy.io/docs/config#environment-variables

I must have overlooked that bit of documentation. At the first glance, seems like it could be sufficient. I'll test it tomorrow and update you on the results.

[siggisim]

Great, let us know if you run into any issues. We're happy to help!

[siggisim]

Feel free to re-open if you run into any issues with this approach!