-
Notifications
You must be signed in to change notification settings - Fork 122
Issue with getting Region when federated #49
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
Comments
And oddly enough adding this...
...fixes the issue. Just do not understand it. I have the |
What version are you using? This should have been addressed by the regional client supplier added in 1.3.1. It's hard to tell without seeing your exact config and how you are using federated sessions, but I suspect that when you load the credentials for the federated session, the credential loader is not looking in your config for a default region. |
Thanks for the help. Here's my set up...
~/.aws/credentials
~/.aws/config
Using 1.3.2 of the SDK now (was at 1.3.1). And now using the KmsMasterKeyProvider builder.
Yields:
Adding `.withDefaultRegion("us-east-1")
Yields
The region is definitely not getting set. Or it is getting overwritten. Seems to find the credentials just fine. |
And going back the old way (now deprecated):
Gives me:
Crazy. |
So to get this working I have use 1.3.1 - and explicitly set the region. Which is of course not what I want. The region needs to be set at runtime. What on earth can be wrong here? |
Were you using 1.3.1 when you had to set the region? As of 1.3.1 the KMS master key provider should automatically vend a KMS master key for the right region on decrypt based on the ARN in the header. EDIT: Sorry, re-read and saw you're using 1.3.2 now. |
When using 1.3.1 the region was undetermined, so the provider could not vend a key. By explicitly adding the region on the provider - it worked. Key is still undetermined when using 1.3.2, and there is not way to set the region. |
This has to be an issue with the credentials/profile loader in the SDK. Or I'm just doing something wrong in my credentials/config setup. I do not think this has anything to do with the Encryption SDK. |
Normally, if you use the builder, the KMSMasterKeyProvider should find the appropriate region by examining the key ID in the ciphertext headers during the decrypt flow. It's strange that this isn't working. How are you generating your ciphertexts? If it's possible to attach a ciphertext generated using a test key, we could take a look at the headers and see if the region is missing somehow. |
Sure. I can upload an encrypted file in bit. Thanks for the help. When the region is explicitly set, the provider vends the correct key. So when the region is not set, it seems the "region chain" logic (or whatever determines the region to use) is not working. Like I said, this works when using a IAM user and not a federated user. |
Here's example ciphertext created by a test key. |
Btw, I appear to have similar issues with the S3 SDK. It does not find the default region when I'm federated. So this must be a local config issue, or a broader SDK issue. |
The strange thing is your message "Can't use keys from region null" - this shouldn't depend on your configuration at all, but instead the region name should come from a parsed arn (see KmsMasterKeyProvider.java:452). I just stepped through a decrypt on my end and it did identify the correct region (and then failed because I don't have access to your key). So I'm a bit stumped. Would it be possible to have you set a breakpoint on KmsMasterKeyProvider.getMasterKey and see what its |
Ok. So I think I found the issue. I was able to fix this in If I do not explicitly set a region, the I only used a single key - in us-east-1 - when I created the encrypted file. So I added a key in us-west-2 - re-encrypted using both keys, and I was able to decrypt as expected without explicitly setting the region! It worked EXACTLY like before. And... before... I did encrypt with two keys - one from us-east-1 and one from us-west-2. It was only TODAY that I encrypted with a single key in us-east-1. So it appears in 1.3.1 you need use a key in us-west-2. I do wonder if all my KMS calls are going to us-west-2 as well. Maybe I'll turn on debug logging and see. In hopes this was also the issue with 1.3.2, I upgraded and changed the code to the
Very odd. Hope this helps. Will keep digging. And will try to do the breakpoint you asked for. |
Ok. My bad. When using 1.3.2 the |
Will this not work in 1.3.2, where
|
Moved above that worked in 1.3.1 to builder for 1.3.2. Getting NPE when calling
|
I apologize for all the spin. To recap. I assumed if a region was not passed to the master key provider on decryption - the current region would be used to vend the resign-specific key. This is not the case. It simply used us-west-2 if the region was not specified. And that is why when I only had a us-east-1 key, I would get an error saying it could not use that key. Adding a us-west-2 key fixed this issue - but exposed a logic error on my part. I believe I need to build the provider with the current region to get the behavior I want (vending the region-specific key). This was all masked in my previous tests since I used two keys - one being us-west-2. It was only when I move to a single key in us-east-1 where I saw the behavior. I wrongly assumed the issue was with my credentials and local region config. Moving to 1.3.2 does expose another issue for me. NullPointer when using the builder in the previous comment, where I'm trying to get a masker key using an alias and region. Maybe you could offer some guidance there. Thank you for your patience. Again, I apologies for the swirl. |
I'm not sure this is actually resolved. In 1.3.2, normally, you should be able to decrypt using keys from any region, using a single MKP. If it's reporting that it can't use region "null" this suggests to me that the wrong key ID is making it into the ciphertext, but that doesn't appear to be the case in the ciphertext you sent. So I'm still very confused about how this is happening. Would it be possible to get the value of |
Since I haven't seen any full stack traces: Is this on encrypt or decrypt? |
The null was on encrypt. I missed that in my hurried state yesterday. I then opened #50. I will say this explains why my KMS calls were all going to us-west-2. :) |
Okay, that explains things then. We'll get the fix merged and spin a new version. Thanks for reporting this! |
Sure. Sorry again for all the spin. |
Wondering if there is an issue with getting the region when the profile is federated. I am in a federated account using a role that has
kms:*
, and I get this when decrypting:This is not an issue with using aliases. This works perfect in another account where I am not federated, using an IAM User with full admin permissions. Is there something else needed here?
The text was updated successfully, but these errors were encountered: