st2chatops env/secrets management

[valentintorikian]

Hey there !

Currently the injection of secret in st2chatops is done through an env variable mapping. The env is iterated over as follow: https://github.com/StackStorm/stackstorm-ha/blob/85c21ed9e925b6fabcbcdef6eae3e5ee04cd8b34/templates/secrets_st2chatops.yaml#L18-L21

This seems to be a bit counter intuitive. From the end user point of view, the env is never referenced as being secret, but every K\V is stored as a secret in k8s.

In addition to this, if we wanted to inject custom env variables that don't have anything secret (eg: proxy settings or equivalent) they will forcefully be stored as secret.

I ran into this issue when trying to allow injection of arbitrary env variables into the deployments.

One solution would be using secrets.st2 for the variables that should be stored as secret, and a classic st2chatops.env or more generally (st2chatops|st2actionrunner|st2api|...).env variable to store the "standard" environment. This can be loosely linked to #14

[mickmcgrath13]

I think this is a good idea. I'd recommend doing st2chatops.env for standard env variables and something like st2chatops.secrets (or st2chatops.envSecrets or similar) for secrets like:

st2chatops:
  secrets:
    HUBOT_ADAPTER: slack
    HUBOT_SLACK_TOKEN: xoxb-CHANGE-ME-PLEASE
  env:
    FOO: bar

[valentintorikian]

I did something comparable, you can checkout the associated PR :).

[arm4b]

In addition to this, if we wanted to inject custom env variables that don't have anything secret (eg: proxy settings or equivalent) they will forcefully be stored as secret.

I don't think there is a harm in forcefully storing ENV variables as secrets. Eg. you don't know if ENV variable from the Helm perspective contains secret data or not and if you're passing sensitive data via specific ENV.

With the beforementioned proposal there is a chance of conflicts and misuse like this:

st2chatops:
  secrets:
    # non-secret, but defined as secret
    HUBOT_ADAPTER: slack
    HUBOT_SLACK_TOKEN: xoxb-CHANGE-ME-PLEASE
  env:
    # conflict
    HUBOT_ADAPTER: non-slack
    # conflict
    HUBOT_SLACK_TOKEN: xoxb-CHANGE-ME-PLEASE1
    # secret, defined as non-secret
    ANOTHER_SECRET: value
    FOO: bar

And so any custom ENV variables to override would be more straightforward to define like that:

st2chatops:
  env:
    HUBOT_ADAPTER: slack
    HUBOT_SLACK_TOKEN: xoxb-CHANGE-ME-PLEASE
    FOO: bar

[arm4b]

I think it's a good idea to explore the official Helm charts and research examples about how majority approach it and what's the established/most obvious way there.

BTW is there a practical downside by having a chance to store a non-secret data as secret? I just assume it's better comparing to storing secret data as non-secret, but there could be more I'm missing.

[mickmcgrath13]

BTW is there a practical downside by having a chance to store a non-secret data as secret?

Size limits. Secrets max size is 1mb

[valentintorikian]

To be noted when using env and envFrom in the same spec: values defined by an Env with a duplicate key will take precedence. Also, inside env, in case of duplicated the last value defined will be used.