Redis API is masking the account key being used

[tombuildsstuff]

👋

We're seeing an issue with the Redis API where the RDB Storage Connection string sent to Azure is different to the one returned from the API, for instance we see the response:

DefaultEndpointsProtocol=https;BlobEndpoint=https://unlikely23exst2acct4u0j.blob.core.windows.net/;AccountName=unlikely23exst2acct4u0j;AccountKey=[key hidden]

rather than the original value posted

DefaultEndpointsProtocol=https;BlobEndpoint=https://unlikely23exst2acct4u0j.blob.core.windows.net/;AccountName=unlikely23exst2acct4u0j;AccountKey=Fv5Ien72PEKr++K8tp5L/fR3qlPghHUiRqHZZS25dR9LsnD//tz8lXLGRORCkBnwrXxltCrx2qjEOZAmGIEgGA==

which in our case is leading to spurious diff's; whilst we could look into ignoring the returned "[key hidden]" value, this makes it impossible for us to detect changes.

Would it be possible to fix the API to return the key that's being used?

Thanks!

[TimLovellSmith]

@tombuildsstuff BTW don't forget to rotate that storage account key!

[tombuildsstuff]

@TimLovellSmith should have mentioned this was an acceptance test, so the Redis Cache in question's already been deleted :)

[TimLovellSmith]

@tombuildsstuff
We are intentionally masking it out in responses to help you avoid unintended information disclosure, since azure permissions to view related storage account credentials should not be implied by azure permissions to get general information about a redis cache.

[tombuildsstuff]

@TimLovellSmith so how are users expected to know which access key is being used when rotating secrets for example? Whilst this is potentially useful for scenarios in the Azure Portal; this approach has the potential to cause production incidents for example where an operator is unsure which key is currently in use, and cycles the wrong one. As such can we look into adding an override/flag to return this information?

Thanks!

[TimLovellSmith]

@tombuildsstuff
Assuming you have enough permissions and you don't know which key is being used, and you want to rotate specifically one of the keys, then you can just reconfigure your redis cache to use the key you are not going to rotate, before you rotate.

[tombuildsstuff]

@TimLovellSmith whilst that approach could work, that's not a suitable workaround in all situations unfortunately - other API's within Azure expose a sensitive endpoint which returns sensitive information; could we get a similar endpoint added to the Redis API?

cc @joshgav @marstr @jhendrixMSFT - this is the issue I was referring too in our meeting the other day

[marstr]

Adding labels to help with our tracking systems.

[TimLovellSmith]

@tombuildsstuff Got some examples of those APIs? I don't know what exactly you are thinking of and it would probably be useful to be able to make the same comparison.

[tombuildsstuff]

@TimLovellSmith off the top of my head - AKS returns an access profile which includes all the sensitive K8S information; App Service returns the connection strings etc.