aws-sdk-rust
aws-sdk-rust copied to clipboard
[request]: No Credential / Iam Policy Support
Tell us about your request
The aws_config crate assumes that you need to have an aws_access_key_id and an aws_secret_access_key. It will try different locations in order to find these credentials. However, when you are writing a lambda function, it is better to control its access rights using an Iam policy. Which means, you do not need to an an aws_access_key_id and an aws_secret_access_key. You only need the region.
Tell us about the problem you're trying to solve.
I want to save the time in checking env and file locations when developing a lamda function as this could shave off a few ms during runtime.
I propose we have a new from_region like so:
aws_config::from_region(region_provider).load()
Or perhaps a new() function which with option<T> for the aws_access_key_id and aws_secret_access_key.
this would assume that you have the access rights to AWS services eg. S3, DynamoDB, etc...
Are you currently working around this issue?
No. I haven't found a work around. Its difficult are to instantiate the aws_config without the aws_credentials.
Additional context
Maybe from_iam_policy is a better name.
I believe lambda functions will provide credentials via environment variables. The first provider in the chain is the environment variable provider, so I would be pretty surprised if you see credentials loading take more than single digit microseconds. If you don't, that's definitely a bug. Any logging you have from the aws-config crate would be helpful.
One thing you could do to be totally sure is to set the credentials provider to the Environment variable credentials provider directly.
@rcoh Without that feature I'm not able to develop apps that rely on various AWS credentials for different functionality. This is quite limiting. For instance I got credentials from a third party to access resources and also got credentials for resources in my own account.
I'm not sure I understand exactly what you're asking for, but it sounds like you want to customize the credential provider(s) used for any given piece of functionality. You can do that today when you create your clients. For example:
// Get the overall default configuration, including the Lambda's initial credentials
let sdk_config = aws_config::load_from_env().await;
// Now we want to use DynamoDB with a specific IAM role that the Lambda
// is allowed to assume that has specific policies
let dynamo_config = aws_sdk_dynamodb::config::Builder::from(&sdk_config)
.credentials_provider(
AssumeRoleProvider::builder("some-role-arn")
.region(Region::from_static("some-region"))
.session_name("some-session-name")
.build(sdk_config.credentials_provider().unwrap().clone())
)
.build();
let dynamo_client = aws_sdk_dynamodb::Client::from_conf(dynamo_config);
If you needed to access resources in multiple AWS accounts or regions, then you could create a separate client for each one with a separate set of credential providers.
If you're using a credentials profile file, I think you can also just declare your named profiles in there, and then use ProfileFileCredentialsProvider::builder().profile_name("the-named-profile").build() as the credential provider.
Is that what you are looking for?
Is there a way to pass access key and secret as function parameters? I could not find the documentation about this.
@HuakunShen To manually create a Credentials struct, you need to enable the hardcoded-credentials feature:
aws-credential-types = { git = "https://github.com/awslabs/aws-sdk-rust", branch = "next", features = [
"hardcoded-credentials",
] }
We feature-gate this because we don't want to encourage customers to do it. We consider hard-coding your credentials to be a bad security process.
Are you still running into this problem?
Greetings! It looks like this issue hasn’t been active in longer than a week. We encourage you to check if this is still an issue in the latest release. Because it has been longer than a week since the last update on this, and in the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please feel free to provide a comment or add an upvote to prevent automatic closure, or if the issue is already closed, please feel free to open a new one.