-
-
Notifications
You must be signed in to change notification settings - Fork 299
Support S3 authentication via IAM Role credentials #8610
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
After taking another look at the "Open Connection" and "Add Bookmark" dialog boxes, I see that the actual structure of these dialogs is pretty much fixed across all the different providers, and the only thing that varies, is the labeling of a few fields (cred-related) and also the options that are available in the "Connect Mode" drop-down. To keep consistent with this approach, this feature could be implemented either (1) as a completely new provider type (S3 IAM Role) or (2) as a drop-down selection for the "Connect Mode" option under the S3 provider. |
Refer to IAM Roles for Amazon EC2. |
Do you run Cyberduck on a Windows EC2 instance? |
This feature would also be very suitable when running Cyberduck CLI on a Linux instance. |
Replying to [comment:3 dkocher]:
Yes, we're rolling out a few intances in AWS right now and each one is assigned an IAM Role specific to their function or service class. Those roles determine permissions the instances inherit to support their functions wrt/ calls and access to different AWS services and resources, including S3 where the different instances have access to different buckets and actions. |
I was reviewing some of the relevant code to implement this request, and I thought of another way to add the functionality with minimal disruption to the existing UI or codebase as starting point. Instead of touching any of the UI elements at all, a special sentinel value, such as Looking at the latest version of the code base in trunk for S3Session.java (source/ch/cyberduck/core/s3/S3Session.java @ 64deab7), at line 114 where you handle switching between an anonymous connection (null AWSCredentials) or constucting a set of credentials based on user-provided Access Key + Secret Key, you could add a third option when The Access Key, Secret Key and Session Token would all be derived from the running context as described above. |
In a7868f8. Untested besides unit tests. Please install the S3 (Temporary Credentials).cyberduckprofile profile and give it a try with the latest snapshot build. |
Documentation in Connecting with temporary access credentials from EC2. |
We have verified this works with Cyberduck CLI on EC2. Change the default role name
|
We verified this works as designed, thank you! Sorry for the delay, we did not expect you would have addressed this ticket so fast and made it available in a short-term release, so it took us a bit to be able to test it. |
Would it be possible to add support for authentication to AWS S3 using Access Key credentials that are derived from an IAM Role on an EC2 instance?
IAM Roles allow you to assign a set of permissions to a resource that is actually deployed in the AWS environment. The way this is implemented is that a set of credentials (Access Key + Secret Key + Session Token) are dynamically assigned and rotated to a particular AWS resources, such as an EC2 Instance.
The Access Key credentials can be retrieved on an EC2 instance by accessing its own instance meta data via the URL:
The last component of that URL path (
THIS_IS_THE_ROLE_NAME
) is actually the name of the role assigned, but it is the only entry in that path, so to get to it programmatically, you would need to call its parent URL and find the only returned value in the response, and then retrieve the target URL which contains the actual credentials.The actual credentials returned look like the following JSON fragment:
From this response you can get the following 3 components which are needed to authenticate requests to the AWS S3 API:
AccessKeyId
- the Access KeySecretAccessKey
- the Secret KeyToken
- the Session TokenYou can also obtain the
LastUpdated
andExpiration
components which indicate when the credentials were last generated, as well as when they will expire and be rotated once again.For CyberDuck, the request I'm making is to add an option flag to the S3 connection settings to indicate the use of IAM Role credentials (similar to the existing "Anonymous" flag). When set, CyberDuck would obtain the current Role credentials as described above, and store them in the current user session, and with every API call to S3, verify the creds are still valid (by comparing current time against the expected Expiration time), and use those creds to authenticate/authorize each API request.
This will allow CyberDuck to be used on an EC2 instance within AWS assuming the IAM Role access policies.
The text was updated successfully, but these errors were encountered: