Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

azurerm_storage_account reveals sensitive data in console #1239

Closed
subesokun opened this issue May 15, 2018 · 4 comments · Fixed by #1242
Closed

azurerm_storage_account reveals sensitive data in console #1239

subesokun opened this issue May 15, 2018 · 4 comments · Fixed by #1242

Comments

@subesokun
Copy link

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

Terraform v0.11.7
provider.azurerm: version = "~> 1.4"

Affected Resource(s)

  • azurerm_storage_account

Expected Behavior

While creating or applying an execution plan no sensitive data should be printed into the console logs. This is very important in case TF is running as part of a CI/CD pipeline.

Actual Behavior

If TF detects a change on a azurerm_storage_account resource and needs to recreate it then sensitive data such as the primary access key for the current active storage accounts gets printed in clear text into the console. This is very critical if your CI/CD pipeline just performed the planning step but did not execute yet the plan as in our case sometimes a manual approval is required before we allow the execution of the plan. As the current active primary access key gets revealed anybody with access to the console logs is now able to infiltrate the storage account.

List of attributes that should be marked as sensitive to avoid this issue:

  • primary_access_key
  • primary_blob_connection_string
  • primary_connection_string
  • secondary_access_key
  • secondary_blob_connection_string
  • secondary_connection_string

Steps to Reproduce

  1. terraform apply
  2. Change some attribute that causes an recreation of the storage account resource (e.g. changing the name)
  3. terraform plan
@katbyte
Copy link
Collaborator

katbyte commented May 15, 2018

@subesokun,

Thanks again for noticing this 🙂 I looked for this problem in other resources and discovered it in over 20 other resources 😅

I have just opened a PR (#1242) that will resolve all the ones I found in v1.6.0.

@subesokun
Copy link
Author

@katbyte Thanks a lot for your efforts! I was already worried if I've to create now for every resource such an issue 😅But with your PR #1242 all my problems will be solved at once 👍

@katbyte
Copy link
Collaborator

katbyte commented May 25, 2018

Hey @subesokun,

Just wanted to let you know we have released v1.6.0 of the provider fixing this leakage of sensitive info.

@ghost
Copy link

ghost commented Mar 31, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!

@ghost ghost locked and limited conversation to collaborators Mar 31, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
2 participants