Secure config vars

[capeterson]

We'd like to provide enhanced security for the most sensitive of config vars for Heroku apps. While config vars are masked today unless you click on them to unmask the ability to unmask at all can be undesirable for some levels of secrets.

Workarounds exist of limiting access to the production app, but having config vars that are specifically noted as extra sensitive that become write-only, and cannot be extracted via the Heroku dashboard, seems like a way to make this level of security much more approachable.

[JoshReedSchramm]

One suggestion as you look into this. It would be great if this were permission based where you could have people w/ the ability to deploy but not view the config vars.

[andre5oto]

@JoshReedSchramm please see roadmap item https://github.com/heroku/roadmap/issues/105. You will be pleased to see your suggestion there as well.

[edmorley]

Currently an app's env vars are accessible via the following means:

• Heroku dashboard
• Heroku CLI / the Heroku's platform API - both via the config vars command/endpoint and the releases command/endpoint
• (By application code or buildpacks only) During builds (excl container builds, where app env vars are not available)
• (By application code only) During Release Phase
• (By application code only) In standard formation dynos
• In a Heroku Exec session connected to a standard formation dyno
• In one-off dynos

At the least, any secure config vars would have to be made available during Release Phase and in standard formation dynos, so the app can function. These are only accessible from application code, but are still accessible via a malicious deploy (ie: by anyone with git push access, access to commit to an auto-deployed GitHub branch, or access to change the buildpacks set on the app) - however that is more noisy than just fetching a secret from the dashboard/API, so presumably still an improvement?

Would secure env vars be available to any of the other items on the list above? I'm guessing perhaps:

• Heroku Exec: No
• One-off dynos: No
• Builds: Maybe - given (a) they often need access to secrets (as much as we try and discourage that in the 12-factor paradigm), (b) it would need a malicious deploy to exfiltrate, at which point the risk overlaps with the standard formation case above.

[edmorley]

Builds: Maybe - given ..., (b) it would need a malicious deploy to exfiltrate, at which point the risk overlaps with the standard formation case above.

So it's occurred to me that there is a slight difference between the builds and standard formation dynos case - if someone pushes some malicious code, but deliberately makes the build fail, it won't get deployed. This means it's less visible to the other app maintainers, since:

• it will just look like a failed build in the app activity log
• no new slug will get uploaded (which would potentially contain the malicious code, leaving a paper trail that can be searched later)

Therefore maybe there is a case for excluding secure env vars from builds too?

[andre5oto]

Thank you @edmorley for this excellent summary. We want to narrow down the exposure of config vars from all members of an Enterprise team. We will begin exploring non-code accessibility (i.e., Dashboard, CLI, API) but doesn't mean we will leave out methods for accessing config vars in code and builds.

[ombr]

It would be great if the access to addons could follow the access given on Heroku. For example If I grant a user a read-only access to my app, I hope they would be able to see the logs and dashboard of the database, but not make any thing dangerous to the state of the app.

[andre5oto]

@ombr thank you for your comment. This sounds like a request for addons to inherit the permissions of an app user, but not related to config vars. Would it be better to list in https://github.com/heroku/roadmap/issues/147 (Improvements to Add-on controls)?

[andre5oto]

Update: we have begun internal testing on a feature to mask sensitive config var values for Heroku PG and Redis add-ons. We will be introducing a pilot soon where customer can participate and test this feature.

[abinoda]

Any update on this?

[capeterson]

@abinoda in the testing we found a couple places that we missed in our initial scoping of this that also can display config vars within the Heroku dashboard, and have to circle back and get a couple cross-team dependencies sorted out to clean them up. We're absolutely still working on this, but that did delay our plans since I don't believe launching a pilot where some config vars subject to this setting were still readable in another page was particularly useful.

Sorry for that - hope we'll have more news to share in the coming months. I'm personally a huge fan of this feature too, can't wait to share more when we're able to.

[abinoda]

Any update on this?

[andre5oto]

@abinoda, yes! We have been doing some improvements as mentioned in the post above by @capeterson. We plan on making the pilot available to Heroku users at the beginning of June (~ June 10th). Stay tuned for a pilot announcement coming soon.

[andre5oto]

Update: getting through some administrative details and hope to have this pilot in your hands by mid-July.

[andre5oto]

We are pleased to announce the limited availability of the Write-Only Config Vars pilot. This is a preview of how we plan to mask sensitive values stored in config vars. In order to participate, please have each user who wishes to participate complete this form.

We strongly advise that you do NOT run this pilot in any production environment. Each user selected for the pilot will receive an email with instructions on how to proceed. Thank you for your interest in helping us develop this very important feature.