# AWS Monad provides comprehensive integration with Amazon Web Services (AWS) through a suite of specialized connectors. Each connector is designed to efficiently extract data from specific AWS services while maintaining security best practices and optimal performance. ## Authentication Methods AWS connectors support the following authentication methods. Choose the one that fits your deployment and security requirements: ### 1. IAM Role Assumption (Recommended) **How it works:** Monad assumes an IAM role in your AWS account using cross-account access with an external ID for additional security. **Setup Requirements:** 1. Create an IAM role in your AWS account 2. Configure the trust relationship (see template below) 3. Attach the necessary permissions for the specific service (the permissions required per connector are given in each connector's docs) 4. Provide the Role ARN to Monad **Trust Relationship Template:** ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "AssumeRoleWithExternalId", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::339712996529:role/monad-app" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "{your-organization-id}" } } }, { "Sid": "TagSession", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::339712996529:role/monad-app" }, "Action": "sts:TagSession" } ] } ``` > **Note:** Replace `{your-organization-id}` with your actual Monad organization ID for better security. ### 2. Static Credentials (Access Key + Secret Key) **Setup Requirements:** 1. Create an IAM user with programmatic access 2. Attach the necessary permissions for the specific service (the permissions required per connector are given in each connector's docs) 3. Generate Access Key ID and Secret Access Key 4. Provide credentials to Monad securely ### 3. OIDC Web-Identity Federation (Kubernetes deployments outside AWS) **When to use:** Monad deployments running on a Kubernetes cluster outside AWS — for example Azure AKS or Google GKE. Rather than trusting a shared Monad role or providing static keys, your AWS connectors federate directly into your AWS account using the cluster's OpenID Connect (OIDC) identity — short-lived credentials, no stored secrets, and no cross-cloud shared principal. The setup is identical regardless of which cloud hosts the cluster; only the issuer URL differs (the cluster's issuer must be publicly reachable by AWS, which every managed Kubernetes offering provides). **How it works:** the connector pod presents its Kubernetes OIDC token to AWS STS (`AssumeRoleWithWebIdentity`) to assume a **web-identity role** in your account, which then assumes the **target role** you point the connector at: ``` connector pod --(OIDC web-identity)--> web-identity role --(AssumeRole)--> target role (holds the data permissions) ``` **Monad provides you:** - your cluster's **OIDC issuer URL** — the format is cloud-specific (e.g. Azure AKS: `https://westus2.oic.prod-aks.azure.com///`; GKE: `https://container.googleapis.com/v1/projects//locations//clusters/`); use exactly what Monad provides - the connector **subject(s)** — for example `system:serviceaccount::inputs` (and a `...:outputs` subject if you use AWS output connectors) - the **audience**: `sts.amazonaws.com` - your **Monad organization ID** (used as the external ID on the target role) **Setup (in your AWS account):** 1. Create an **IAM OIDC identity provider** for the issuer URL, with `sts.amazonaws.com` as the audience (client ID). 2. Create a **web-identity role** trusted by that provider for your connector subject (template below), and give it permission to assume the target role. 3. Create a **target role** (one per connector) that trusts the web-identity role and holds the actual permissions (e.g. SQS). **Web-identity role — trust policy:** ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam:::oidc-provider/" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { ":aud": "sts.amazonaws.com", ":sub": "system:serviceaccount::inputs" } } } ] } ``` **Web-identity role — permission to assume the target role:** ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam:::role/" } ] } ``` **Target role — trust policy:** ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam:::role/" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": "{your-organization-id}" } } } ] } ``` **Then:** 1. Provide the **web-identity role ARN** to Monad — it is attached to your connectors' Kubernetes service accounts. 2. Set each AWS connector's **Role ARN** to its **target role** ARN. > **Note:** `` is the issuer URL with `https://` removed. Match it **exactly** as Monad provides it — in the OIDC provider, the `Federated` principal, and the `:aud`/`:sub` condition keys — **including a trailing slash if the issuer has one** (Azure AKS issuers end with one; GKE issuers do not). A stray or missing trailing slash causes a silent trust failure. If you use both input and output connectors, list both subjects in the `:sub` condition (it accepts a JSON array), or use `StringLike` with `system:serviceaccount::*`. ## Common Configuration Parameters Most AWS connectors share these common configuration options: | Parameter | Type | Required | Description | |-----------|------|----------|-------------| | **Region** | string | Yes | AWS region where the service is located | | **Role ARN** | string | Conditional* | IAM role ARN for role-based authentication | | **Access Key** | string | Conditional* | AWS Access Key ID for static credentials | | **Secret Key** | string | Conditional* | AWS Secret Access Key for static credentials | *Required based on your chosen authentication method ## Related Resources - [AWS IAM Best Practices](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)