Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] secret support #76

Closed
garthy opened this issue Apr 26, 2024 · 4 comments
Closed

[FEATURE] secret support #76

garthy opened this issue Apr 26, 2024 · 4 comments
Labels
new feature/idea New feature or request

Comments

@garthy
Copy link

garthy commented Apr 26, 2024

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

    workload-one-example:
        command:
            - -c
            - while true; do echo $${CONNECTION}; sleep 5; done
        depends_on:
            wait-for-resources:
                condition: service_started
                required: false
        entrypoint:
            - /bin/sh
        environment:
            CONNECTION: redis://default:XfygjA6Kxtb6mfXZ@redis-FUxtcv:6379
        hostname: workload-one
        image: busybox

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

Copy link

Thank you for your issue. Give us a little time to review it.

PS. You might want to check the FAQ if you haven't done so already.

This is an automated reply, generated by FAQtory

@astromechza
Copy link
Member

@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.

@astromechza astromechza added the new feature/idea New feature or request label May 29, 2024
@astromechza
Copy link
Member

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.

@garthy
Copy link
Author

garthy commented Nov 11, 2024

You mentioned docker secrests (Which require swarm) but docker-compose allows configuring things marked as secrets which is better than nothing?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new feature/idea New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants