compose-spec / compose-go

Reference library for parsing and loading Compose YAML files
https://compose-spec.io
Apache License 2.0
350 stars 109 forks source link

feat(compose-spec): Add content property for secrets in compose-spec.json #669

Closed idsulik closed 2 days ago

idsulik commented 1 month ago

Fixes https://github.com/docker/compose/issues/12033

Add content to secret property, because in case of environment value, we add "content" property but it wasn't defined in the spec

ndeloof commented 1 month ago

we add "content" property but it wasn't defined in the spec

This is by design: we don't want sensible data to be exposed as plain text in a compose file

idsulik commented 1 month ago

@ndeloof good point, thank you! pushed fix. Added validation to prevent from specifying "content" for the secrets property

ndeloof commented 1 month ago

SecretConfig already has a custom MarshalJSON so that content is excluded from json output. But with use of map[string]any for yaml processing, this isn't used by gojsonschema validator. Will need to find an equivalent hack

ndeloof commented 1 week ago

Suggestion: to avoid letting content be used in compose.yaml and miss it during validation, resolved value could be stored in map with key #value (with a #) which makes it an invalid key in yaml (until user set key with quote, but this can't be by accident then).

idsulik commented 1 week ago

Suggestion: to avoid letting content be used in compose.yaml and miss it during validation, resolved value could be stored in map with key #value (with a #) which makes it an invalid key in yaml (until user set key with quote, but this can't be by accident then).

@ndeloof , if you mean this changes:

# environment.go
        if found, ok := environment[env]; ok {
            secret["#value"] = found
        }

then it won'r work:

secrets.one-secret-token Additional property #value is not allowed

ndeloof commented 1 week ago

oh indeed.

ndeloof commented 3 days ago

A possible workaround is to use a fake extension key x-#value that would be valid regarding the spec

idsulik commented 3 days ago

A possible workaround is to use a fake extension key x-#value that would be valid regarding the spec

I'm not sure I get the idea if I rename

if found, ok := environment[env]; ok {
    secret["content"] = found
}

into

if found, ok := environment[env]; ok {
    secret["x-#value"] = found
}

Then how do we map this key into the Secret struct's content field?

ndeloof commented 3 days ago

Then how do we map this key into the Secret struct's content field?

need to add a DecodeMapstructure func to FileObjectConfig so it detects this custom key is set and use it as value

idsulik commented 3 days ago

@ndeloof pushed changes.
p.s. extracted the key name into constant for consistency

idsulik commented 2 days ago

@glours done