Feature: support AWS WebIdentityProvider credentials configuration
#2168
Labels
Comments
|
Thanks for filing this. Agree that we should probably move off and support the recommended configuration path. Is that something you think the Khalani team could take on? |
|
related re: rusoto - probably makes sense to switch when ethers-rs does gakonst/ethers-rs#2312 |
serejke
added a commit
to tvl-labs/hyperlane-monorepo
that referenced
this issue
May 4, 2023
serejke
added a commit
to tvl-labs/hyperlane-monorepo
that referenced
this issue
May 4, 2023
serejke
added a commit
to tvl-labs/hyperlane-monorepo
that referenced
this issue
May 10, 2023
serejke
added a commit
to tvl-labs/hyperlane-monorepo
that referenced
this issue
May 15, 2023
serejke
added a commit
to tvl-labs/hyperlane-monorepo
that referenced
this issue
May 15, 2023
serejke
added a commit
to tvl-labs/hyperlane-monorepo
that referenced
this issue
May 18, 2023
serejke
added a commit
to tvl-labs/hyperlane-monorepo
that referenced
this issue
May 19, 2023
asaj
pushed a commit
that referenced
this issue
May 19, 2023
### Description Support of web identity AWS credentials: #2168 ### Drive-by changes `WebIdentityProvider` resides in `rusoto_sts`, I had to add a dependency on `rusoto_sts = "*"`. ### Backward compatibility _Are these changes backward compatible?_ Yes. The newly added `AwsChainCredentialsProvider` preserves 100% compatibility with clients using `EnvironmentProvider`. We tested the following scenarios: 1) Run agent with `AWS_ACCESS_KEY_ID` / `AWS_SECRET_ACCESS_KEY` / `AWS_SESSION_TOKEN` credentials — the current default behavior — works as before. 2) Without envs from p.1 but with `AWS_WEB_IDENTITY_TOKEN_FILE` / `AWS_ROLE_ARN` / `AWS_ROLE_SESSION_NAME` injected by AWS EKS pod identity [webhook](https://github.com/aws/amazon-eks-pod-identity-webhook) — works well. We ran the agents for 24+ hours to make sure the JWT gets refreshed automatically. 3) Without any envs — the app expectedly fails with "environment variable not found" error. _Are there any infrastructure implications, e.g. changes that would prohibit deploying older commits using this infra tooling?_ None ### Testing Manual: we deployed a Hyperlane agent Docker image built from our [fork](https://github.com/tvl-labs/hyperlane-monorepo/pkgs/container/hyperlane-monorepo).
|
closed by #2188 |
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Objective
Currently, the only way to configure AWS credentials for agents to access S3 and KMS is by passing env variables
AWS_ACCESS_KEY_IDandAWS_SECRET_ACCESS_KEY. This is not the best security practice as the specified credentials never expire.The recommended approach for integrating AWS roles for EKS pods is to use IAM roles for
ServiceAccount(IRSA). The IRSA webhook automatically sets upAWS_WEB_IDENTITY_TOKEN_FILEandAWS_ROLE_ARNenv variables on the pod, and mounts the web identity token file.What needs to be changed in code
Hyperlane uses rusoto SDK for AWS services, which, by the way, is in maintenance mode (consider migrating to the official AWS SDK for Rust ?).
Rusoto has a
ProvideAwsCredentialstrait, which has several implementations. Currently, theEnvironmentProvideris used:hyperlane-monorepo/rust/hyperlane-base/src/settings/signers.rs
Line 112 in 1722f4e
hyperlane-monorepo/rust/hyperlane-base/src/types/s3_storage.rs
Line 96 in 03d32f4
we can provide a configuration flag to use WebIdentityProvider instead.
Suggestion:
SignerConf.Awshyperlane-monorepo/rust/hyperlane-base/src/settings/signers.rs
Line 24 in 1722f4e
can be extended with a new
credentials_type: AwsCredentialsTypeenumAwsCredentialsType = EnvironmentVariables | WebIdentityFilewith the default value ofEnvironmentVariables, and depending on the enum value, theEnvironmentProviderorWebIdentityProvideris created.Related discussion
This issue was first discovered by @kuzirashi and mentioned in Discord.
The text was updated successfully, but these errors were encountered: