# IAM Role的应用场景

[IAM Role是什么](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles.html)。您可以使用Amazon CLI或Amazon API或使用自定义URL来代入roles。有关role使用的更多信息，请参阅[IAM用户指南](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles_use.html)。

IAM roles可以用临时权限，在以下场景中非常有用：

## 单点登录

当联合身份进行身份验证时，该身份将与角色关联，并被授予由角色定义的权限。有关联合身份验证角色的信息，请参阅 IAM 用户指南 中的[为第三方身份提供商创建角色](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles_create_for-idp.html)。

## 临时IAM user权限

IAM 用户或角色可以代入 IAM 角色，以临时获取特定任务的不同权限。请参阅IAM用户指南中的[如何切换role](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)。

## 跨账号访问

你可以使用IAM role允许某人（a trusted principal）在不同的账户中访问AWS的资源。Role是跨账号授权的主要方式。

#### 如何通过IAM角色实现跨账号访问

要实现跨账号访问，您需要在拥有资源的账户中创建一个IAM角色，并定义一个信任策略，允许另一个账户的用户、服务或角色扮演这个角色。跨账号访问通常涉及两个账户：资源拥有者账户（生产账号）和请求者账户（开发账号）。

**创建IAM角色**

1. 登录到AWS管理控制台。
2. 打开IAM控制台。
3. 选择**角色**，然后选择**创建角色**。
4. 选择**另一个AWS账户**，输入可以扮演角色的账户ID。
5. 选择**下一步：权限**，为角色选择合适的权限策略。
6. 选择**下一步：标签**（可选）。
7. 选择**下一步：审查**，为角色命名并审查。
8. 选择**创建角色**。

**配置信任关系**

编辑刚创建的IAM角色，添加信任关系：

```json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::请求者账户ID:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

**在请求者账户中扮演角色**

1. 请求者账户使用AWS STS服务的`AssumeRole`API操作来请求扮演角色。
2. 如果请求成功，用户将获得一个包含访问密钥、密钥ID及会话令牌的临时安全凭证。
3. 请求者使用这些临时凭证来访问资源拥有者账户中的资源。

**示例**

开发人员在开发账号中需要访问生产账号中的S3存储桶。生产账号创建了一个允许访问该S3存储桶的IAM角色，并允许开发账号扮演这个角色。开发人员可以使用`AssumeRole`操作获得临时凭证，并使用这些凭证访问存储桶。

## 跨服务访问

例如，在服务调用的时候，可能会在Amazon EC2中运行应用程序，或者在Amazon S3中存储对象。服务在做调用的时候需要使用Principal permissions，service role或者service-linked role。

* **Principal permissions** – 使用某些服务时，可能会执行一个操作，然后在其他服务中触发另一个操作。在这种情况下，您必须具有执行这两个操作的权限。查看一个操作是否需要额外的操作授权，参见此[帮助文档](https://docs.amazonaws.cn/service-authorization/latest/reference/reference.html)。
* **Service role** – Service role是服务代入IAM role，用于代表你执行操作。IAM管理员可以创建，修改和删除service role。更多信息参见 [创建向 Amazon 服务委派权限的角色](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles_create_for-service.html)。
* **Service-linked role** - service-linked role是一种service role关联到一个Amazon web Service。服务可以代入角色代表你执行操作。Service-linked roles由service拥有，IAM管理员可以查看但是不能修改service-linked roles的权限。

下面假设要让EC2实例上运行的应用程序能够访问同一个账号下的S3存储桶以及跨账号的存储桶，您需要为EC2绑定的IAM角色配置两种策略：一种是直接访问同账号下的S3存储桶的策略，另一种是允许跨账号访问的策略。

#### 直接访问同账号S3存储桶的策略示例

```json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::你的存储桶名字/*"
        }
    ]
}
```

#### 允许跨账号访问的策略示例

首先，目标账号（存储桶所在账号）需要创建一个允许跨账号访问的策略，并附加到要访问的S3存储桶上。

```json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {"AWS": "开发账号的ARN"},
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::跨账号存储桶的名字/*"
        }
    ]
}
```

然后，在开发账号（EC2实例所在账号）的IAM角色策略中添加允许使用 `sts:AssumeRole` 来扮演目标账号允许的角色，以获得访问权限。

```json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "目标账号允许访问的角色的ARN"
        }
    ]
}
```

使用这两种策略配置，EC2实例上的应用程序将能够访问同账号下的S3存储桶以及跨账号的S3存储桶。

## 运行在Amazon EC2上的应用

使用IAM role来管理临时凭证，比在 EC2 实例中存储访问密钥更安全。有关更多信息，请参阅 IAM 用户指南中的 [使用 IAM 角色向在 Amazon EC2 实例上运行的应用程序授予权限](https://docs.amazonaws.cn/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)。

#### IAM角色与EC2实例的关联

IAM角色可用于为在Amazon EC2实例上运行的应用程序提供必要的AWS权限。这避免了将访问密钥直接存储在EC2实例上，提高了安全性。IAM角色授予的权限由策略决定，这些策略指定了角色可以执行哪些AWS服务和资源上的操作。

**步骤概述：**

1. **创建IAM角色**：首先，在IAM中创建一个角色，并附加一组策略，这些策略定义了角色的权限。
2. **将角色附加到EC2实例**：创建或现有的EC2实例可以被指定这个IAM角色。这样，运行在EC2实例上的应用程序就可以利用这个角色的权限，而不需要管理静态的AWS访问密钥。
3. **在应用程序中利用IAM角色**：应用程序可以通过AWS SDK或命令行工具自动获取与角色关联的临时凭证。这些凭证可用于执行允许的AWS服务调用。

使用IAM角色向运行在Amazon EC2实例上的应用程序授予权限，既提高了安全性，也简化了凭证管理流程。

## 运行在Amazon EKS上的应用

使用IAM role来管理临时凭证，比在 EKS中存储访问密钥AK/SK更安全。

EKS上配置IAM角色以供Pods使用：

1. **创建IAM角色和策略**：首先创建一个IAM角色，然后创建或关联一个策略，该策略规定了对AWS服务的访问权限。确保策略满足你的应用需求。
2. **使用IAM roles for service accounts (IRSA)**：利用EKS的IAM roles for service accounts (IRSA)功能，允许Kubernetes服务帐户关联IAM角色。这样，运行在EKS上的Pods可以使用该服务帐户的权限，从而通过AWS的临时凭证访问AWS资源，无需管理静态的访问密钥。
3. **创建OIDC身份提供者**：在EKS集群中创建OIDC（OpenID Connect）身份提供者。这一步是启用IRSA的前提。
4. **关联IAM角色和Kubernetes服务账号**：创建一个Kubernetes服务账号，并通过注解将其与IAM角色关联。这样，在此服务账号下运行的Pods就有权使用IAM角色的权限。

#### 示例：

```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  namespace: my-namespace
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-iam-role
```

通过这种方式，EKS上运行的应用程序能够更安全、更方便地管理对AWS资源的访问权限。
