[question]: is there a reason why the rc uses env and not secrets?

[aledbf]

Something like one secret per version or the one secret per app that is updated in each version.

[bacongobbler]

it's a holdover from deis v1. Are you referring to something like deis/deis#4480?

[helgi]

Not all env vars need to be secrets, at least in my opinion. Particularly because secrets are files (until maybe 1.2 or later based on kubernetes/kubernetes#4710) oppose to ENV vars.

If you look at #13 I had brought up the idea of being able to pass in something like --secret on config:set to achieve what you might want. Is that along the lines of what you want?

Basically proposing we have the ability to set ENV without throwing them into secrets and some that will go in there. Things like DEBUG=true isn't inherently needed as a secret :)

[aledbf]

Are you referring to something like deis/deis#4480?

@bacongobbler yes

[aledbf]

like --secret on config:set to achieve what you might want

@helgi yes, something like that to protect "important" things :)

[aledbf]

@helgi with env vars is not possible to use the authorization plugins (abac)
For instance one user can do a rolling update changing one or more values in env without problem, that is not possible if the user is not allowed to do that.

[helgi]

@aledbf I think we are on the same page mostly. Use k8s env for "less important" and secrets (via flag) for "important" things and that gets via the usual k8s path ways, probably would expose it as an internal ENV var when that issue lands.

Are you talking about when the user decides to bypass Deis for the rolling update and go directly to k8s? Do you have a link to the auth plugin?

[aledbf]

@helgi here
authorization.md
example

[helgi]

I'll have to look at it in more detail but there is no way this would cover the env portion in the future? Especially when the pod templates become their own real separate resource out from RCs?