Amazon Web Services 连接

Amazon Web Services 连接类型启用 AWS 集成

重要

Amazon Web Services 连接可以在 UI/API 中测试,或通过调用 test_connection() 进行测试,正确解释此测试结果是**重要**的。在测试期间,Amazon Provider 的组件调用 AWS Security Token Service API GetCallerIdentity。此服务**只能**检查您的凭证是否有效。不幸的是,它无法验证凭证是否拥有访问特定 AWS 服务的权限。

如果您使用 Amazon Provider 与 AWS API 兼容服务(MinIO、LocalStack 等)通信,连接测试失败**不意味着**您的连接凭证是错误的。许多兼容服务仅提供有限数量的 AWS API 服务,并且大多数不实现 AWS STS GetCallerIdentity 方法。

向 AWS 进行身份验证

可以使用 Boto3 指南 凭证 中描述的任何选项进行身份验证。此外,可以将凭证作为连接初始化参数传入。

要使用 IAM 实例配置文件,请创建一个“空”连接(即,未指定 AWS 访问密钥 ID 或 AWS 秘密访问密钥,或使用 aws:// 的连接)。

默认连接 ID

默认连接 ID 是 aws_default。如果运行 Airflow 的环境/机器在 ${HOME}/.aws/ 中有文件凭证,并且默认连接的用户和密码字段为空,它将自动从那里获取凭证。

重要

以前,aws_default 连接在安装时将“extras”字段设置为 {"region_name": "us-east-1"}。这意味着默认情况下,aws_default 连接使用 us-east-1 区域。现在不再是这种情况,区域需要手动设置,可以在 Airflow 的连接屏幕中设置,或通过 AWS_DEFAULT_REGION 环境变量设置。

注意

如果您没有运行“airflow connections create-default-connections”命令,则很可能您没有 aws_default。出于历史原因,Amazon Provider 组件(Hooks、Operators、Sensors 等)在缺少连接 ID 的情况下回退到默认的 boto3 凭证策略。

如果您需要使用默认的 boto3 凭证策略(环境变量中的凭证、IAM 配置文件等),请提供 None,而不是缺少连接 ID,以避免在日志中收到警告。

配置连接

AWS Access Key ID (可选)

指定用于初始连接的 AWS 访问密钥 ID。如果您通过在 **Extra** 字段中指定 role_arn 来执行 assume role,则后续对 AWS 的调用将使用临时凭证。

AWS Secret Access Key (可选)

指定用于初始连接的 AWS 秘密访问密钥。如果您通过在 **Extra** 字段中指定 role_arn 来执行 assume role,则后续对 AWS 的调用将使用临时凭证。

Extra (可选)

指定 AWS 连接中可以使用的额外参数(以 json 字典形式)。所有参数都是可选的。

以下额外参数用于创建初始的 boto3.session.Session

  • aws_access_key_id: 用于初始连接的 AWS access key ID。

  • aws_secret_access_key: 用于初始连接的 AWS secret access key

  • aws_session_token: 如果您使用外部凭证,则用于初始连接的 AWS 会话令牌。您负责更新这些令牌。

  • region_name: 连接的 AWS 区域。

  • profile_name: 配置和凭证文件设置中列出的要使用的配置文件名称。

以下额外参数用于 assume role

  • role_arn: 如果指定,则 assume 此角色,使用 assume_role_method 获取一组临时安全凭证。

  • assume_role_method: AWS STS 客户端方法,可以是 assume_roleassume_role_with_samlassume_role_with_web_identity。如果未指定,则使用 **assume_role**。

  • assume_role_kwargs: 传递给 assume_role_method 的额外 **kwargs**。

如果 assume_role_method 设置为 assume_role_with_web_identity,则以下额外参数可用

  • assume_role_with_web_identity_federation: federation 类型,用于确定使用哪个令牌加载器来检索访问令牌。目前支持 filegoogle

  • assume_role_with_web_identity_token_file: 对于 file federation 类型,文件系统上包含用于向 AWS STS 服务进行身份验证的访问令牌的文件的路径。如果未指定,则将使用 AWS_WEB_IDENTITY_TOKEN_FILE 环境变量的值。

  • assume_role_with_web_identity_federation_audience: 如果使用 google federation 类型,则为访问令牌的 aud claim。

以下额外参数传递给 boto3.session.Session.client()boto3.session.Session.resource()

  • config_kwargs: 用于构造 botocore.config.Config 的额外 **kwargs**。要匿名访问公共 AWS 资源(相当于 signature_version=botocore.UNSGINED),请在 config_kwargs 中设置 “signature_version”=”unsigned”

  • endpoint_url: 连接的全局 Endpoint URL。您可以通过利用 service_config 为每个 AWS 服务指定 endpoint url,详情请参考 AWS 服务 Endpoint URL 配置

  • verify: 是否验证 SSL 证书。

    • False - 不验证 SSL 证书。

    • **path/to/cert/bundle.pem** - 要使用的 CA 证书捆绑包的文件名。如果您想使用与 botocore 使用的 CA 证书捆绑包不同的捆绑包,可以指定此参数。

以下额外参数用于特定的 AWS 服务

  • service_config: 用于指定每个 AWS 服务 / Amazon provider hook 的配置/参数的 json,详情请参考 按服务配置

如果您通过 URI 配置连接,请确保 URI 的所有组件都已进行 URL 编码。

示例

创建连接并转换为 URI 的代码片段

import os
from airflow.models.connection import Connection


conn = Connection(
    conn_id="sample_aws_connection",
    conn_type="aws",
    login="AKIAIOSFODNN7EXAMPLE",  # Reference to AWS Access Key ID
    password="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",  # Reference to AWS Secret Access Key
    extra={
        # Specify extra parameters here
        "region_name": "eu-central-1",
    },
)

# Generate Environment Variable Name and Connection URI
env_key = f"AIRFLOW_CONN_{conn.conn_id.upper()}"
conn_uri = conn.get_uri()
print(f"{env_key}={conn_uri}")
# AIRFLOW_CONN_SAMPLE_AWS_CONNECTION=aws://AKIAIOSFODNN7EXAMPLE:wJalrXUtnFEMI%2FK7MDENG%2FbPxRfiCYEXAMPLEKEY@/?region_name=eu-central-1

os.environ[env_key] = conn_uri
print(conn.test_connection())  # Validate connection credentials.

警告

使用 Airflow CLI 时,当以下字段未给出时,可能需要在 URI 末尾添加一个 @

  • login

  • password

  • host

  • port

参见下面的示例。这是一个已知的 airflow 限制。

airflow connections add aws_conn --conn-uri aws://@/?region_name=eu-west-1

使用 instance profile

这将使用 boto 的默认凭证查找链(来自 ~/.boto/ 配置文件中名为 “default” 的配置文件,以及在 AWS 内部运行时使用的 instance profile)

URI 格式示例

export AIRFLOW_CONN_AWS_DEFAULT=aws://

JSON 格式示例

export AIRFLOW_CONN_AWS_DEFAULT='{"conn_type": "aws"}'

使用 AWS IAM 密钥对

URI 格式示例

export AIRFLOW_CONN_AWS_DEFAULT=aws://AKIAIOSFODNN7EXAMPLE:wJalrXUtnFEMI%2FK7MDENG%2FbPxRfiCYEXAMPLEKEY@

请注意,秘密访问密钥已进行 URL 编码(将 / 更改为 %2F),并且还有尾随的 @(如果没有它,将被视为 <host>:<port> 并且无法工作)

JSON 格式示例

export AIRFLOW_CONN_AWS_DEFAULT='{
  "conn_type": "aws",
  "login": "AKIAIOSFODNN7EXAMPLE",
  "password": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
}'

Extra 字段的示例

  1. 使用 *~/.aws/credentials* 和 *~/.aws/config* 文件,并带有配置文件。

这假定所有其他连接字段(例如 **AWS Access Key ID** 或 **AWS Secret Access Key**)都为空。

{
  "profile_name": "my_profile"
}
  1. 指定要 assume 的 role_arn 和 region_name

{
  "role_arn": "arn:aws:iam::112223334444:role/my_role",
  "region_name": "ap-southeast-2"
}
  1. 配置出站 HTTP 代理

{
  "config_kwargs": {
    "proxies": {
      "http": "http://myproxy.mycompany.local:8080",
      "https": "http://myproxy.mycompany.local:8080"
    }
  }
}
  1. 使用 AssumeRoleWithWebIdentity(基于文件的令牌)

{
  "role_arn": "arn:aws:iam::112223334444:role/my_role",
  "assume_role_method": "assume_role_with_web_identity",
  "assume_role_with_web_identity_federation": "file",
  "assume_role_with_web_identity_token_file": "/path/to/access_token"
}
  1. 使用 AssumeRoleWithSAML

{
  "region_name":"eu-west-1",
  "role_arn":"arn:aws:iam::112223334444:role/my_role",
  "assume_role_method":"assume_role_with_saml",
  "assume_role_with_saml":{
    "principal_arn":"arn:aws:iam::112223334444:saml-provider/my_saml_provider",
    "idp_url":"https://idp.mycompany.local/.../saml/clients/amazon-aws",
    "idp_auth_method":"http_spegno_auth",
    "mutual_authentication":"OPTIONAL",
    "idp_request_kwargs":{
      "headers":{"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"},
      "verify":false
    },
    "idp_request_retry_kwargs": {
      "total": 10,
      "backoff_factor":1,
      "status":10,
      "status_forcelist": [400, 429, 500, 502, 503, 504]
    },
    "log_idp_response":false,
    "saml_response_xpath":"////INPUT[@NAME='SAMLResponse']/@VALUE",
  },
  "assume_role_kwargs": { "something":"something" }
}

以下设置可在 Extra 中的 assume_role_with_saml 容器中使用。

  • principal_arn: 在 IAM 中创建的 SAML provider 的 ARN,它描述了身份提供者。

  • idp_url: 您的 IDP 端点的 URL,提供 SAML Assertions。

  • idp_auth_method: 指定 “http_spegno_auth” 以使用 Python requests_gssapi 库。此库比 requests_kerberos 更新,并且向后兼容。请参阅 PyPI 上的 requests_gssapi 文档。

  • mutual_authentication: 可以是 “REQUIRED”、“OPTIONAL” 或 “DISABLED”。请参阅 PyPI 上的 requests_gssapi 文档。

  • idp_request_kwargs: 向 IDP 请求时(通过 HTTP/S)传递给 requests 的额外 kwargs

  • idp_request_retry_kwargs: 用于构造 urllib3.util.Retry 的额外 kwargs,用作向 IDP 请求时的重试策略。

  • log_idp_response: 有助于调试 - 如果指定,将 IDP 响应内容打印到日志。请注意,成功的响应将包含敏感信息!

  • saml_response_xpath: 如何使用 XML / HTML xpath 查询 IDP 响应。

  • assume_role_kwargs: 传递给 sts_client.assume_role_with_saml 的额外 kwargs

注意

requests_gssapi 库用于从您的 IDP 获取 SAML 响应。您可能需要 pip uninstall python-gssapipip install gssapi 才能使其工作。 python-gssapi 库已过时,并与 Airflow 在其他地方使用的一些 paramiko 版本冲突。

按服务配置

AWS 服务 Endpoint URL 配置

要在单个连接中为特定 AWS 服务使用 endpoint_url,您可以在服务配置中设置它。要强制执行默认的 botocore/boto3 行为,您可以将值设置为 null。优先级规则如下

  1. 按服务级别指定的 endpoint_url

  2. 在连接 extra 的根级别指定的 endpoint_url。请注意,在 assume role 或连接测试中使用的 **sts** 客户端不使用全局参数。

  3. 默认的 botocore/boto3 行为

{
  "endpoint_url": "s3.amazonaws.com"
  "service_config": {
    "s3": {
      "endpoint_url": "https://s3.eu-west-1.amazonaws.com"
    },
    "sts": {
      "endpoint_url": "https://sts.eu-west-2.amazonaws.com"
    },
    "ec2": {
      "endpoint_url": null
    }
  }
}

S3 桶配置

要在 S3Hook 方法中按连接使用 S3 桶名称,请在连接的 extra 字段中提供选定的选项。

注意

hook 方法中的 bucket_name 参数将覆盖此连接设置。

{
  "service_config": {
    "s3": {
      "bucket_name": "awesome-bucket"
    }
  }
}

避免限流异常

Amazon Web Services 对并发 API 调用有限额,因此频繁调用 apache-airflow-providers-amazon 组件在执行期间可能会因限流异常而失败,例如 *ThrottlingException*、*ProvisionedThroughputExceededException*。

botocore.config.Config 原生支持不同的指数退避模式:legacystandardadaptive

默认情况下,botocore.config.Config 使用 legacy 模式,最多重试 5 次,这在某些情况下可能不够。

如果您遇到限流异常,可以将模式更改为 standard,并增加重试次数。

另请参阅

在连接中设置

连接 extra 字段:
{
  "config_kwargs": {
    "retries": {
      "mode": "standard",
      "max_attempts": 10
    }
  }
}

在 AWS 配置文件中设置

~/.aws/config:
[profile awesome_aws_profile]
retry_mode = standard
max_attempts = 10
连接 extra 字段:
{
  "profile_name": "awesome_aws_profile"
}

通过环境变量设置

注意

这将设置所有连接的重试模式,除非在特定连接上显式设置了其他重试配置。

export AWS_RETRY_MODE=standard
export AWS_MAX_ATTEMPTS=10

Session Factory

连接的默认 BaseSessionFactory 可以处理大多数 AWS 的身份验证方法。如果您想完全控制 boto3.session.Session 的创建,或者您正在使用需要外部进程来获取凭证的自定义 federation,您可以继承 BaseSessionFactory 并根据需要重写 create_session 和/或 _create_basic_session 方法。

您还需要为 AwsBaseHook 添加配置,以便按其完整路径使用自定义实现。

示例

配置:
[aws]
session_factory = my_company.aws.MyCustomSessionFactory
连接 extra 字段:
{
  "federation": {
    "username": "my_username",
    "password": "my_password"
  }
}
自定义 Session Factory:
def get_federated_aws_credentials(username: str, password: str):
    """
    Mock interaction with federation endpoint/process and returns AWS credentials.
    """
    return {
        "Version": 1,
        "AccessKeyId": "key",
        "SecretAccessKey": "secret",
        "SessionToken": "token",
        "Expiration": "2050-12-31T00:00:00.000Z",
    }


class MyCustomSessionFactory(BaseSessionFactory):
    @property
    def federated(self):
        return "federation" in self.extra_config

    def _create_basic_session(self, session_kwargs: dict[str, Any]) -> boto3.session.Session:
        if self.federated:
            return self._create_federated_session(session_kwargs)
        else:
            return super()._create_basic_session(session_kwargs)

    def _create_federated_session(self, session_kwargs: dict[str, Any]) -> boto3.session.Session:
        username = self.extra_config["federation"]["username"]
        region_name = self._get_region_name()
        self.log.debug(
            f"Creating federated session with username={username} region_name={region_name} for "
            f"connection {self.conn.conn_id}"
        )
        credentials = RefreshableCredentials.create_from_metadata(
            metadata=self._refresh_federated_credentials(),
            refresh_using=self._refresh_federated_credentials,
            method="custom-federation",
        )
        session = botocore.session.get_session()
        session._credentials = credentials
        session.set_config_variable("region", region_name)
        return boto3.session.Session(botocore_session=session, **session_kwargs)

    def _refresh_federated_credentials(self) -> dict[str, str]:
        self.log.debug("Refreshing federated AWS credentials")
        credentials = get_federated_aws_credentials(**self.extra_config["federation"])
        access_key_id = credentials["AccessKeyId"]
        expiry_time = credentials["Expiration"]
        self.log.info(
            f"New federated AWS credentials received with aws_access_key_id={access_key_id} and "
            f"expiry_time={expiry_time} for connection {self.conn.conn_id}"
        )
        return {
            "access_key": access_key_id,
            "secret_key": credentials["SecretAccessKey"],
            "token": credentials["SessionToken"],
            "expiry_time": expiry_time,
        }

使用 Web Identity Federation 进行 Google Cloud 到 AWS 身份验证

得益于 Web Identity Federation,您可以使用 Google Cloud 平台上的凭证授权访问 Amazon Web Service 平台。如果您另外使用从 元数据服务器Workload Identity 获取访问令牌的授权,您可以通过消除长期有效的凭证来提高环境安全性。

Google Cloud 凭证通过 AWS Security Token Service 交换为 Amazon Web Service 临时凭证

下图说明了用于获取 AWS 凭证的典型通信流程。

../_images/aws-web-identity-federation-gcp.png

通信流程图

角色设置

为了让 AWS 识别 Google 身份,您必须在 AWS 中配置角色。

您可以使用角色向导或使用 Terraform 来完成。

角色向导

创建 web identity federation 的 IAM 角色

  1. 登录 AWS 管理控制台并在 https://console.aws.amazon.com/iam/ 打开 IAM 控制台。

  2. 在导航窗格中,选择 **角色 (Roles)**,然后选择 **创建角色 (Create role)**。

  3. 选择 **Web identity** 角色类型。

  4. 对于身份提供者 (Identity provider),选择 **Google**。

  5. 在 **Audience** 框中输入服务账号电子邮件地址(格式为 <NAME>@<PROJECT_ID>.iam.gserviceaccount.com)。

  6. 检查您的 web identity 信息,然后选择 **下一步: 权限 (Next: Permissions)**。

  7. 选择用于权限策略的策略,或选择 **创建策略 (Create policy)** 以打开新的浏览器标签页并从头开始创建新策略。更多信息请参阅 创建 IAM 策略 (Creating IAM Policy)

  8. 选择 **下一步: 标签 (Next: Tags)**。

  9. (可选) 通过将标签添加为键值对来向角色添加元数据。有关在 IAM 中使用标签的更多信息,请参阅 标记 IAM 用户和角色 (Tagging IAM users and roles)

  10. 选择 **下一步: 审核 (Next: Review)**。

  11. 对于 **角色名称 (Role name)**,输入角色名称。角色名称在您的 AWS 账户中必须是唯一的。

  12. (可选) 对于 **角色描述 (Role description)**,输入新角色的描述。

  13. 审核角色,然后选择 **创建角色 (Create role)**。

更多信息请参阅:为 web identity 或 OpenID connect federation 创建角色(控制台)

最后,您应该获得一个具有类似如下策略的角色

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "accounts.google.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "accounts.google.com:aud": "<NAME>@<PROJECT_ID>.iam.gserviceaccount.com"
        }
      }
    }
  ]
}

为了防止 Google OpenID 令牌被滥用,您还可以通过配置每个 audience 的限制来限制使用范围。您需要在连接中配置相同的值,然后此值也将包含在 ID Token 中。AWS 将测试此值是否匹配。为此,您可以向策略添加新的条件。

{
  "Condition": {
    "StringEquals": {
      "accounts.google.com:aud": "<NAME>@<PROJECT_ID>.iam.gserviceaccount.com",
      "accounts.google.com:oaud": "service-amp.my-company.com"
    }
  }
}

创建角色后,您应该在 Airflow 中配置连接。

Terraform

为了快速配置新角色,您可以使用以下 Terraform 脚本,该脚本配置 AWS 角色及其分配的策略。在使用之前,您需要修改 locals 部分中的变量以适应您的环境

  • google_service_account - 将有权使用此角色的服务账号的电子邮件地址

  • google_openid_audience - 在 Airflow 角色和连接中配置的常量值。它防止 Google ID 令牌被滥用。

  • aws_role_name - 新 AWS 角色的名称。

  • aws_policy_name - 新 AWS 策略的名称。

有关使用 Terraform 脚本的更多信息,请参阅:Terraform 文档 - 入门 - AWS

执行计划后,您应该在 Airflow 中配置连接。

连接设置

为了使用 Google 身份,连接设置的 extra 部分中字段 "assume_role_method" 必须是 "assume_role_with_web_identity",字段 "assume_role_with_web_identity_federation" 必须是 "google"。它还要求您在 "role_arn" 字段中设置角色。可选地,您可以通过配置 "assume_role_with_web_identity_federation_audience" 字段来限制 Google Open ID 令牌的使用。这些字段的值必须与角色中配置的值匹配。

Airflow 将根据 应用程序默认凭证 (Application Default Credentials) 建立 Google 的凭证。

下面是一个连接配置示例。

{
  "role_arn": "arn:aws:iam::240057002457:role/WebIdentity-Role",
  "assume_role_method": "assume_role_with_web_identity",
  "assume_role_with_web_identity_federation": "google",
  "assume_role_with_web_identity_federation_audience": "service_a.apache.com"
}

您也可以使用环境变量 AIRFLOW_CONN_{CONN_ID} 来配置连接。

export AIRFLOW_CONN_AWS_DEFAULT="aws://\
?role_arn=arn%3Aaws%3Aiam%3A%3A240057002457%3Arole%2FWebIdentity-Role&\
assume_role_method=assume_role_with_web_identity&\
assume_role_with_web_identity_federation=google&\
assume_role_with_web_identity_federation_audience=aaa.polidea.com"

在 EKS 上使用 IAM Roles for Service Accounts (IRSA)

如果您在 Amazon EKS 上运行 Airflow,您可以通过将 IAM 角色授予 Airflow 的服务账号来授予 AWS 相关权限(例如用于远程日志记录的 S3 读取/写入)。IRSA 为在 EKS 上运行并使用其他 AWS 服务(例如 Pod)的应用程序提供细粒度的权限管理。这些应用程序可能使用 S3,或任何其他 AWS 服务,如 Secrets Manager、CloudWatch、DynamoDB 等。

要激活此功能,必须遵循以下步骤

  1. 在 EKS 集群上创建一个 IAM OIDC Provider。

  2. 创建一个 IAM 角色和策略,并将其附加到 Airflow 服务账号,使用步骤 1 中创建的 web identity provider。

  3. 将相应的 IAM 角色作为注解添加到 Airflow 服务账号。

然后您可以在相应的 Pod 的环境变量中找到 AWS_ROLE_ARNAWS_WEB_IDENTITY_TOKEN_FILE,这些是由 Amazon EKS Pod Identity Web Hook 添加的。然后 boto3 将使用这些变量配置凭证。为了在 Airflow 中使用 IRSA,您必须创建一个所有字段都为空的 AWS 连接。如果设置了 role-arn 等字段,Airflow 不会遵循 boto3 的默认流程,因为它会手动使用连接字段创建会话。如果您没有更改默认连接 ID,一个名为 aws_default 的空 AWS 连接就足够了。

使用 eksctl 创建 IAM Role for Service Account(IRSA)

eksctl 是一个用于在 EKS 上创建和管理集群的简单 CLI 工具。按照步骤为 Airflow 创建 IRSA。

  1. 在您的本地机器上安装 eksctl

  2. 在您的终端中设置 AWS 凭证以运行 eksctl 命令。

  3. 默认情况下未启用 IAM OIDC Provider,您可以使用以下命令启用。

eksctl utils associate-iam-oidc-provider --cluster="<EKS_CLUSTER_ID>" --approve

4. 替换 EKS_CLUSTER_IDSERVICE_ACCOUNT_NAMENAMESPACE 并执行以下命令。此命令将使用现有的 EKS 集群 ID 并创建一个 IAM 角色、服务账号和 namespace。

eksctl create iamserviceaccount --cluster="<EKS_CLUSTER_ID>" --name="<SERVICE_ACCOUNT_NAME>" --namespace="<NAMESPACE>" --attach-policy-arn="<IAM_POLICY_ARN>" --approve``

这是一个带值的示例命令。此示例使用附加到 IAM 角色的、具有完整 S3 权限的托管策略。我们强烈建议您创建一个受限的 IAM 策略,该策略仅包含 S3、Secrets Manager、CloudWatch 等所需权限,并将其与 --attach-policy-arn 一起使用。

eksctl create iamserviceaccount --cluster=airflow-eks-cluster --name=airflow-sa --namespace=airflow --attach-policy-arn=arn:aws:iam::aws:policy/AmazonS3FullAccess --approve
  1. 在 Airflow Helm chart 部署或 Kubernetes Pod Operator 中使用服务账户名称。

使用 Terraform 创建服务账户的 IAM 角色 (IRSA)

对于 Terraform 用户,可以使用 Amazon EKS Blueprints for Terraform 模块创建 IRSA 角色。

此模块创建一个新的 IAM 角色、服务账户和命名空间。这将把 IAM 角色与服务账户关联,并向服务账户添加注解。您需要创建一个包含所需权限的 IAM 策略,这些权限是您希望 Pod 中的容器拥有的。将 IAM_POLICY_ARN 替换为您自己的 IAM 策略 ARN,按照如下所示填写其他所需的输入,然后运行 terraform apply

module "airflow_irsa" {
  source = "github.com/aws-ia/terraform-aws-eks-blueprints//modules/irsa"

  eks_cluster_id             = "<EKS_CLUSTER_ID>"
  eks_oidc_provider_arn      = "<EKS_CLUSTER_OIDC_PROVIDER_ARN>"
  irsa_iam_policies          = ["<IAM_POLICY_ARN>"]
  kubernetes_namespace       = "<NAMESPACE>"
  kubernetes_service_account = "<SERVICE_ACCOUNT_NAME>"
}

应用 Terraform 模块后,您就可以在您的 Airflow 部署或 Kubernetes Pod Operator 中使用该服务账户了。

本条目有帮助吗?