Skip to content

IAM Role and Policy Configuration

The IAM role and policy configuration is designed to implement the principle of least privilege, ensuring that each entity (Lambda function and organization users) has only the permissions necessary to perform its intended functions:

Lambda Function Role and Policy

Lambda Function Role:

  • Allows the Lambda function to assume the role and execute.
  • Grants permission to read from Secrets Manager to access mnemonics.
  • Provides access to CloudWatch for logging.

Trust Policy

A trust policy defines which AWS services or users can assume a specific role. For the Lambda function, we create a trust policy that allows the Lambda service to assume the role:

json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Lambda Function Policy

This policy specifies the exact permissions for the Lambda function

json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:*"
    },
    {
      "Effect": "Allow",
      "Action": ["iam:ListUserPolicies", "iam:GetUserPolicy"],
      "Resource": "arn:aws:iam::489278327972:user/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue",
        "secretsmanager:CreateSecret",
        "secretsmanager:PutSecretValue"
      ],
      "Resource": "arn:aws:secretsmanager:us-east-1:489278327972:secret:*"
    }
  ]
}

This policy allows the Lambda function to:

  • Create and manage CloudWatch log groups and streams
  • List and get IAM user policies
  • Get, create, and update secrets in Secrets Manager

Organization User Policy

In our setup, each organization has its own dedicated IAM (Identity and Access Management) user.

This approach provides several benefits:

Isolation: Each organization has its own set of access keys, ensuring that they can only access their own resources.

Fine-grained control: We can apply specific policies to each IAM user, controlling exactly what AWS resources and actions they can access.

Secure mnemonic storage: Each organization can store its mnemonic securely under a unique secret ID in AWS Secrets Manager. The IAM user is granted permissions to access only their specific secret, enhancing security and preventing unauthorized access to other organizations' mnemonics.

The policy for each organization user includes:

json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue",
        "secretsmanager:CreateSecret",
        "secretsmanager:PutSecretValue"
      ],
      "Resource": "arn:aws:secretsmanager:us-east-1:489278327972:secret:<buyer>/*"
    },
    {
      "Effect": "Allow",
      "Action": ["lambda:InvokeFunction"],
      "Resource": "arn:aws:lambda:us-east-1:489278327972:function:<SkcEthSigner>"
    },
    {
      "Effect": "Allow",
      "Action": "execute-api:Invoke",
      "Resource": "arn:aws:execute-api:us-east-1:489278327972:<givuqcikd9>/prod/POST/sign"
    },
    {
      "Effect": "Allow",
      "Action": ["apigateway:*"],
      "Resource": "*"
    }
  ]
}

This policy allows each organization to:

  • Manage their own secrets in Secrets Manager
  • Invoke the specific Lambda function for transaction signing
  • Invoke the API Gateway endpoint for signing
  • Perform necessary API Gateway actions

These roles and policies work together to ensure secure operation of the signing service while maintaining separation between different organizations' resources.

Secure Mnemonic Handling with Secret Manager

AWS Secrets Manager plays a crucial role in our secure handling of mnemonics:

Unique Secret ID: Each organization's mnemonic is stored under a unique secret ID in Secrets Manager. This ID is typically associated with the organization's name or identifier.

Secure Storage: Mnemonics are encrypted at rest and in transit, ensuring their confidentiality.

Access Control: The IAM policy for each organization's user is configured to allow access only to their specific secret ID. This ensures that organizations can retrieve only their own mnemonic.

Retrieval Process: When an organization needs to sign a transaction, their IAM user invokes the Lambda function. The function then retrieves the correct mnemonic from Secrets Manager using the organization's unique secret ID for signing the transactions.

This approach ensures that mnemonics are securely stored and accessed, maintaining the integrity and confidentiality of each organization's Ethereum accounts while allowing for efficient transaction signing.