[Feature Request] Load service credentials from Kubernetes secret

[RobKenis]

Description

When using service widgets, the configuration requires me to pass api keys or passwords, for example key: apikeyapikeyapikeyapikeyapikey for Emby as documented here.
I've been trying my hardest to harden my secret management, but because I store everything in Git, this exposes all my passwords. Would it be possible to store the passwords in a Kubernetes Secret and pass the secret to the configuration?

Other

No response

[glime-ai[bot]]

Based on the context provided, it seems you are looking for a way to securely manage secrets for service widgets in a Kubernetes environment, without exposing sensitive information in your Git repository.

As of the information available up to the knowledge cutoff date, Homepage does not natively support Kubernetes Secrets for service widget configuration. However, there are general practices you can follow to manage secrets securely in Kubernetes:

1. Kubernetes Secrets: You can create Kubernetes Secrets to store sensitive information and then mount those secrets into your pods as environment variables or files. Your application would then read these values at runtime.

2. External Secrets Management: Use a dedicated secrets manager like HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault. These tools can integrate with Kubernetes and provide more robust features for managing secrets.

3. Environment Variables: As mentioned in the context, environment variables can be used to pass secrets to the application. You can define these environment variables in your Kubernetes deployment configuration, referencing the Kubernetes Secrets.

4. Init Containers: Use an init container to fetch secrets from a secure location and write them to a shared volume that your application container can access.

5. Custom Solution: Implement a custom solution within your application to fetch secrets from a secure source at startup.

For your specific case, you would need to modify your application to support reading configuration values from environment variables or files that are populated from Kubernetes Secrets at runtime. This would prevent the need to store sensitive information directly in your Git repository.

Please note that any changes to the application code or deployment strategy to support Kubernetes Secrets would need to be done by the maintainers of the Homepage project or by forking the project and making the necessary modifications yourself.

Remember to follow best practices for secret management, such as limiting access to secrets, using least privilege principles, and regularly rotating secrets.

If you are not the maintainer of the Homepage project, you may want to reach out to the project's maintainers to request this feature or to inquire about the best way to handle secrets for service widgets in a Kubernetes environment.

---

Thanks for posting a discussion about homepage here on GitHub. Homepage now uses a fancy new AI tool thanks to our friends at Glime, so the answer above is the AI bot's attempt to answer your question. If you feel it's sufficient you can mark the answer and close this post, otherwise feel free to leave it open of course!

Thanks for using Homepage! ❤️

[18visions]

I too am struggling with passing my secrets into Kubernetes. Does anyone have any advice, or can point to any examples in github?

[thejimnicholson]

I don't yet have a worked example, but what I've come up with so far is this:

• Create the yaml for a Kubernetes secret using the config files as keys.
• use kubeseal to encrypt the secret. If you are going to commit the deployment files, commit the sealed version, not the config files themselves or the yaml for the secret you generate.
• use volume and volumeMount within the deployment to map the secret keys into a config directory inside the container.

[github-actions[bot]]

This discussion has been automatically closed due to lack of community support. See our contributing guidelines for more details.

[github-actions[bot]]

This discussion has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion for related concerns. See our contributing guidelines for more details.