AWS KMS signer for the Dispatcher

[renan061]

Context

Currently the dispatcher signs transactions by instantiating a local wallet.
It creates the wallet through a mnemonic read from a ENV variable or the configuration file.
This is not secure at all.

Solution

It should be possible to use a signing API like AWS KMS.

Subtasks

• Change the transaction manager configuration.
• Add the proper configurations to the dispatcher.
• Add support for conditional signer instantiation in the dispatcher.
• Implement the AWS KMS signer.

[endersonmaia]

Hey all, I'm testing rollups-dispatcher based on 2e388b7 that support AWS KMS for signing transactions.

In my environment, I'm getting this error :

2023-06-09T20:40:44.145980Z ERROR new{key_id=2a313b66-752b-4787-bddf-bd59309fcdd1}:request_get_pubkey{key_id=2a313b66-752b-4787-bddf-bd59309fcdd1}: ethers_signers::aws: error=Couldn't find AWS credentials in environment, credentials file, or IAM role.
2023-06-09T20:40:44.146044Z ERROR new{key_id=2a313b66-752b-4787-bddf-bd59309fcdd1}: ethers_signers::aws: error=Couldn't find AWS credentials in environment, credentials file, or IAM role.
2023-06-09T20:40:44.146904Z ERROR rollups_dispatcher: Dispatcher stopped: Ok(Err(Failed to initialize the transaction signer

Caused by:
    0: AWS KMS signer error
    1: AWS KMS error
    2: Couldn't find AWS credentials in environment, credentials file, or IAM role.
    3: Couldn't find AWS credentials in environment, credentials file, or IAM role.
    4: Couldn't find AWS credentials in environment, credentials file, or IAM role.))
Error: Failed to initialize the transaction signer

Caused by:
    0: AWS KMS signer error
    1: AWS KMS error
    2: Couldn't find AWS credentials in environment, credentials file, or IAM role.
    3: Couldn't find AWS credentials in environment, credentials file, or IAM role.
    4: Couldn't find AWS credentials in environment, credentials file, or IAM role.

When investigating the environment for the rollups-dispatcher container, I see:

cartesi@echo-python-rollups-validator-node-5bdc488f46-xtccm:/var/opt/cartesi$ env | grep -e ^AWS -e ^AUTH_AWS | sort
AUTH_AWS_KMS_KEY_ID=2a313b66-752b-4787-bddf-bd59309fcdd1
AUTH_AWS_KMS_REGION=us-east-1
AWS_DEFAULT_REGION=us-east-1
AWS_REGION=us-east-1
AWS_ROLE_ARN=arn:aws:iam::[_REDACTED_]:role/staging-us-east-1-clusterkmsauthoritysaRole67327E9-SG1BGE880LOE
AWS_STS_REGIONAL_ENDPOINTS=regional
AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token

Since we use OpenID Connect at our Kubernets cluster, to give access to IAM Roles via an OIDC Provider, we have to support the AWS_WEB_IDENTIFY_TOKEN_FILE variables together with AWS_ROLE_ARN and AWS_ROLE_SESSION_NAME

As you can see at https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-envvars.html

AWS_WEB_IDENTITY_TOKEN_FILE

    Specifies the path to a file that contains an OAuth 2.0 access token or OpenID Connect ID token that is provided by an identity provider. The AWS CLI loads the contents of this file and passes it as the WebIdentityToken argument to the AssumeRoleWithWebIdentity operation.

    Used with the AWS_ROLE_ARN and AWS_ROLE_SESSION_NAME environment variables.

    If defined, this environment variable overrides the value for the profile setting web_identity_token_file.

    For more information on using web identities, see Assume role with web identity.

    > Note
    > This environment variable only applies to an assumed role with web identity provider it does not apply to the general assume role provider configuration.

Should I open a new issue, or reopen this one?

[tuler]

The AWS rust SDK should already automatically support all sorts of authentication, including AWS_WEB_IDENTITY_TOKEN_FILE.

https://docs.aws.amazon.com/sdk-for-rust/latest/dg/environment-variables.html

[tuler]

I don’t think we are instantiating the AWS client the way it’s described in the documentation.

[endersonmaia]

https://github.com/rusoto/rusoto/blob/master/AWS-CREDENTIALS.md Em sex., 9 de jun. de 2023 19:06, Danilo Tuler ***@***.***> escreveu:

…

I don’t think we are instantiating the AWS client the way it’s described in the documentation <https://docs.aws.amazon.com/sdk-for-rust/latest/dg/client.html>. — Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAC4WRRP2ZJQTA4JXA2TDXKOM5FANCNFSM6AAAAAAWRRCPMY> . You are receiving this because you commented.Message ID: ***@***.***>

[tuler]

ethers_signers is using rusoto, not the official SDK. So ignore some links above that point to the official SDK.

It’s not looking like rusoto supports the authentication method of AWS_WEB_IDENTITY_TOKEN_FILE

https://docs.rs/rusoto_credential/0.48.0/rusoto_credential/struct.ChainProvider.html

[tuler]

There is an open issue to move from rusoto to the official SDK

[tuler]

It’s not looking like rusoto supports the authentication method of AWS_WEB_IDENTITY_TOKEN_FILE

It actually does. In this implementation class.

[gligneul]

@tuler @endersonmaia I didn't quite understand the issue. Do you need another authentication method?

[tuler]

The official AWS SDKs supports several authentication methods, including the one used by AWS EKS Service accounts.
We did not anticipate we would need special handling here, but the code of ethers_signers is not using the official SDK.
So yes, we will need a special handling for the authentication used by EKS.

[gligneul]

Ok, now I get it. We will work on it.

[renan061]

The rusoto library currently accepts these methods of authentication in case you want to test with a different config:

The following sources are checked in order for credentials when calling credentials:

    - Environment variables: AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY
    - credential_process command in the AWS config file, usually located at ~/.aws/config.
    - AWS credentials file. Usually located at ~/.aws/credentials.
    - IAM instance profile. Will only work if running on an EC2 instance with an instance profile/role.

As Danilo mentioned, there is already an implementation for the web identity token, so this should not be difficult to change.

Also, we are using rusoto instead of the official SDK because ethers-rs is still using rusoto and the official SDK is not production ready according to its github page.

[endersonmaia]

I don't see WebIdentity as an option in that list.

Is sending a patch upstream to enable WebIdentity a viable option?

Otherwise, we'd need to craft a ~/.aws/credentials file using an external tool like aws sts assume-role-with-web-identity to generate such a file.

[tuler]

We will need an additional flag and implement that option.
Check a similar problem they had here.