There are places where various secrets are needed in most stacks. For example here in the test database stack the password for postgresql is specified in the clear in a compose file: https://github.com/bozemanpass/stack-test-stacks/blob/main/stack-files/compose/composefile-test-database.yml#L29
We need to implement a consistent mechanism for injecting these secrets at deploy time such that they don't appear in the clear in files either in git or on disk in a deployment directory. The mechanism has to look transparent to the user across deployment targets (compose vs k8s). In the k8s case it should leverage cluster secrets.
There may also be some benefit to having stack encapsulate a secret such that the user never defines is nor sees it. This would be useful for example in the example above where there's a database container and a backend api container that's a client of the database. Both need to know the database password, but unless doing debugging/diagnostics nobody else does.
There are places where various secrets are needed in most stacks. For example here in the test database stack the password for postgresql is specified in the clear in a compose file: https://github.com/bozemanpass/stack-test-stacks/blob/main/stack-files/compose/composefile-test-database.yml#L29
We need to implement a consistent mechanism for injecting these secrets at deploy time such that they don't appear in the clear in files either in git or on disk in a deployment directory. The mechanism has to look transparent to the user across deployment targets (compose vs k8s). In the k8s case it should leverage cluster secrets.
There may also be some benefit to having stack encapsulate a secret such that the user never defines is nor sees it. This would be useful for example in the example above where there's a database container and a backend api container that's a client of the database. Both need to know the database password, but unless doing debugging/diagnostics nobody else does.