Customer-managed Keys support to ensure that the encryption keys are sent with every request, including pre-signed URLs. That also means GitLab has to proxy every object storage request because the user browser can't use a pre-signed URL to download or upload data.
I have a few concerns before we go down the route of customer-managed keys:
Do customers care how we store these keys? Right now they would live in our Rails and GitLab configuration files so anyone with admin access can get them. Is there a requirement to use some sort of key management service here?
Do they care about how key rotation will work? We don't have any mechanism to do this at the moment. Right now if you need to rotate the keys, you'll get all sorts of 500 errors when trying to access a file with the wrong key.
Great questions @stanhu. If you rotate keys, does Azure automatically re-encrypt? Is KEK a thing when doing CMK? That would avoid some of the re-encryption challenges potentially.
@stanhu nice! That means you'd just need to pass the updated key to GitLab once you change it in Azure? Seems like there is Azure CLI support for this, so perhaps you could automate the config change along with the rotation in one action.
Although to your point on customer managed identity, that would be even easier.
@stanhu is this something you are planning to work on? If not, I can try to figure out a way to get this moving.
It sounds like the consistent message is that option 2, customer-managed keys (CMK)--not to be confused with customer-provided keys--is the requirement, so this makes life a lot easier. I got confused between the two, and now I appreciate how Amazon calls them by SSE-KMS and SSE-C. It's much clearer that way.
We support CMK just fine. I just did a test:
Nothing changes on our end because the 512-bit storage access key we used to access Azure Storage encrypts the actual customer key.
I will focus my attention on #242245 because I think it's a nice property not to have to specify credentials on a VM.