通过 STS Session Tags 来对 AWS 资源进行更灵活的权限控制

前言

S3是非常受欢迎的云对象存储，很多客户使用S3来存储他们的用户文件。终端用户可以直接通过HTTP的方式上传和管理在S3中的文件，而不需要经过服务器中转。那么如何限制S3对象的访问权限，让终端用户只有管理自己拥有的文件的权限，则成了很多客户关心的问题。熟悉AWS的朋友可能知道，IAM的Policy是用来管理AWS访问权限的，那么如何让Policy更灵活、更动态，可以让获取到的权限凭证可以匹配到单个终端用户的S3文件目录下，是我们今天要讨论的主题。

STS 介绍

您可以用编程方式调用 AWS Security Token Service (AWS STS) 的API，获取访问AWS资源的临时安全凭证，并将这些凭证下发给终端用户，用于后续终端用户发起访问AWS资源请求时进行身份验证。

在调用STS API的过程中，STS支持在请求会话（session）中传入的一个或多个tag参数，tag为Key Value的键值对，在IAM Policy中使用变量名${aws:PrincipalTag/Key}，便可在IAM Policy中获取到Value值。通过在STS session中动态地传入变量值，便可以灵活地为不同的S3对象分配权限。

临时安全凭证与长期有效的安全凭证的区别

熟悉AWS的朋友应该知道，在AWS IAM中创建User后，会分配一对access key ID和secret access key（以下简称AK/SK），在AWS CLI和SDK中都需要配置AK/SK，当以编程方式调用API时，会使用AK/SK对请求执行身份验证，这对AK/SK长期有效。

而临时安全凭证，包含AK/SK和Session Token，AK/SK用于标识用户身份，Session Token用于验证凭证的有效性，AK/SK不随User一起存储，而是动态生成，且使用期限有限，可将这些凭证的有效时间配置几分钟到几小时。

这些差异使得可利用临时凭证获得以下优势：

您不必随应用程序分配或嵌入长期 AWS 安全凭证，降低安全凭证泄露的风险。
可允许用户访问您的 AWS 资源，而不必为这些用户定义 AWS 身份。临时凭证是角色和联合身份验证的基础。
临时安全凭证的使用期限有限，因此，在不需要这些凭证时不必轮换或显式撤销这些凭证。临时安全凭证到期后无法重复使用。

请求流程

通过STS获取临时安全凭证流程如下图。

终端用户的客户端发出访问请求到服务器端。
服务器端调用STS API，以获取临时安全凭证。
STS服务返回临时安全凭证。
Server将获取到的临时安全凭证下发给客户端。
客户端使用临时安全凭证来访问AWS资源，本文中是S3桶。

下面来看下具体如何实现。本文为了方便展示，使用AWS CLI方式来演示整个权限配置和获取的过程，在真实场景中建议在应用中使用AWS SDK代码来实现以上流程。

在AWS云上的配置

在AWS云上创建一个IAM User，名为ServerUser，将其AK/SK配置在服务器端，其至少拥有调用STS AssumeRole操作的权限，如下策略所示。

{
    "Version": "2012-10-17",
    "Statement": [
        {
        "Sid": "VisualEditor0",
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Resource": "*"
        }
    ]
}

创建一个AssumedRole，其所具有的Policy如下。该Policy中BUCKET和PREFIX根据实际情况填写，用${aws:PrincipalTag/userid}来引用STS Session传入的Tag的key，作为变量，来获取到value值，以匹配上实际的目录。文中使用的key是userid，此Policy限定了每个user只能获取其userid目录下的文件列表，和读写和删除的权限。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ListYourObjects",
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": [
                "arn:aws:s3:::BUCKET"
            ],
            "Condition": {
                "StringLike": {
                    "s3:prefix": [
                        "PREFIX/${aws:PrincipalTag/userid}/"
                    ]
                }
            }
        },
        {
            "Sid": "ReadWriteDeleteYourObjects",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::BUCKET/PREFIX/${aws:PrincipalTag/userid}/",
                "arn:aws:s3:::BUCKET/PREFIX/${aws:PrincipalTag/userid}/*",
            ]
        }
    ]
}

修改此AssumedRole的信任关系，如下所示。通过控制台创建的Role的信任关系里的Principal是AWS的服务，在这里需要修改为上一步创建的IAM User，为ServerUser，以信任SeverUser来使用此Role来获取临时凭证。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::account-id:user/ServerUser"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ]
        }
    ]
}

演示

在服务器端，配置AWS CLI，使用ServerUser的AK/SK对。使用CLI，调用assume-role命令，传入tag，key为userid，value为123456，表明为userid为123456的用户生成临时安全凭证。

aws sts assume-role --role-arn arn:aws:iam::account-id:role/AssumedRole --role-session-name my-session --tags Key=userid,Value=123456 —duration-seconds 1800
{
"AssumedRoleUser": {
"AssumedRoleId": "AROA23ZIK3DO7XQDDB4I4:my-session",
"Arn": "arn:aws:sts::account-id:assumed-role/AssumedRole/my-session"
},
"Credentials": {
"SecretAccessKey": "xxxxxxxxxxxxxx",
"SessionToken": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"Expiration": "2020-04-10T07:34:12Z",
"AccessKeyId": "xxxxxxxxxxx"
},
"PackedPolicySize": 3
}

在客户端，使用上一步在服务器端获得的userid为123456的临时安全凭证，这里使用CLI export到环境中。

export AWS_ACCESS_KEY_ID=xxxxxxxxxxx
export AWS_SECRET_ACCESS_KEY=xxxxxxxxxxxxxx
export AWS_SESSION_TOKEN=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

使用CLI上传一个文件到userid为123456的S3目录下，能够成功。

aws s3 cp ./myfile s3://BUCKET/PREFIX/123456/

查看此文件家里的目录，可以看到能够返回文件列表。

aws s3 ls s3://BUCKET/PREFIX/123456/
2020-03-25 08:02:37 0 myfile

尝试查看userid为234567的目录，会返回如下错误。

aws s3 ls s3://xucy-static/app/234567/
An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied

读者可以自行验证读写、删除等操作的权限，本文不再赘述。

小结

在本文中，我们通过STS服务传递session tags实现了终端用户只能管理自己的文件的场景。不难发现，sesstion tags在AWS的权限管理更具灵活性，可基于这些tags来允许或拒绝资源的访问，可将使用场景拓展到别的AWS服务中。

参考资料

https://docs.thinkwithwp.com/zh_cn/IAM/latest/UserGuide/id_credentials_temp_request.html

https://docs.thinkwithwp.com/zh_cn/IAM/latest/UserGuide/id_session-tags.html

亚马逊AWS官方博客