Ability to specify which environment variables are masked by Secret Masking
under review
Nathan Fish
marked this post as
under review
A consideration here I'd like input on. We currently offer contexts and project env vars. My thought is we remove the encryption on project env vars. We keep the encryption on contexts. It's a small change but creates a situation where you can control printout by which one you use.
Nedim Haveric
Nathan Fish Better late then never !
Not sure if that fixes everything - user like to store related things close to each other: think of
AWS_REGION
- it's not a secret, we'd like to see the value in cleartext, and we'd also like to store it next to where the AWS_ACCESS_KEY_ID
et al are.(I know - OIDC etc. but it's just a clear example)
Nathan Fish
Nedim Haveric: That's a great example and good context. It does, however, make options a little more complicated for both the platform and the user. I'll take this back to the team and see what options we might be able to come up with.
Swaraj Rao
Nathan Fish This would not help us, we would like granular control on encryption for each var in the context. We care less about project env vars, if we'd like those to be unencrypted we can easily move it out of project env vars and into the config file directly.
This is much harder to for contexts which might be shared by thousands of different repos. Making a context env var not be masked would involve removing the env var from the context and adding it to each repos project env vars which is incredibly tedious.
J
Jeremy TenWolde
Nathan Fish That is actually terrible for my particular situation. We have a per-project token to access another system. We store the unique token for each project in its env vars and it has to remain masked. Creating a context per project to maintain the encryption would be extra confusing overhead for us.
G
Gustavo Encarnação
We use many environment variables that are not secrets. Being able to see the current value and edit it would be very handy. As it is we currently need to keep these values stored in an external document to be able to edit them and then delete+create the environment value again.
Environment variables =/= Build secrets
G
Greg Ganz
This would be awesome if we could get this, preferably like yesterday :-)
V
Vinay Raghu
Please can we have some prioritization on this. It is difficult when some variables are redacted but they are part of URLs or package names.
D
Daniel Lamando
I've been moving pipelines to passwordless / OIDC authentication, and have zero secrets left in some projects. But because OIDC is configured by environment variables, I still have a bunch of masked variables to set this up, making it impossible to view the current settings. This needs to be prioritized to improve the OIDC auth story. I'd even be happy with disabling masking for entire contexts if nothing else.
L
Loke
I hope this get prioritized soon!
C
Contact
I would love to have this implemented by Circle CI team. This is one of the must have feature and not to force the user with all variables masked and instead better to let user decide which one to mask.
G
Greg Matthews
This would also be super helpful for our builds. We like being able to centralise & manage our environment variables in CircleCI, but don't always use them for storing credentials. Not being able to see their values in this instance detracts from what would otherwise be a really good feature.
P
Patrick Gibson
I came here to log the same issue. It's extremely frustrating to be penalized for not wanting to hardcode certain things like Docker/ECR repos into our build configs. This issue is nearly four years old!
D
Dave Parsons
+100 Major missing feature vs. GitHub Actions.
Load More
→