Closed garthy closed 1 week ago
@garthy thanks for filing the request.
Currently secret outputs from resources being injected into envvars and file mounts are handled by the Score implementations themselves.
Eg: score-k8s will expect the secret to be present in a Kubernetes Secret and then if this is used in an env var or file will use projected volumes or K8s-specific tools to securly mount the secret.
You can create a secret as an output from a resource in score-k8s like this: https://github.com/score-spec/score-k8s/blob/e675f961ad1bf1123bc6efb0a3d1ad17bd657c58/internal/provisioners/default/zz-default.provisioners.yaml#L141
We didn't do this in score-compose because the docker secrets require swarm mode.
It's a good question whether there is a generalisable way of doing this that we could pull into the spec itself. It may be tricky since different runtimes support different interpolations, mount strategies, content lengths, and structures so it may not be possible.
Going to close this as I think as score-k8s provides good guidance as to how secrets should be handled, if we want to open this as an issue against specific score implementations like score-compose, we can do that.
You mentioned docker secrests (Which require swarm) but docker-compose allows configuring things marked as secrets which is better than nothing?
Detailed description
It would be nice if secrets were supported as a first class resource. They could be generated and stored then used to create/access the resource and be passed around securely as well as the platform supports and stop writing them to state/config files. eg:- docker-compose output snippit
Context
secure deployment and configuration and stop secrets getting wrtitten into files and environments
Possible implementation
using docker(-compose) secrets/k8s secrets a secret could be created Then used to create and protect the resource And then used to access the resource.
Additional information
No response