SageMaker JumpStart调用image_uris.retrieve()报AccessDenied如何解决

身份查询方法 #

要确认当前SDK操作实际使用的身份，直接调用STS接口查询即可，执行以下代码：

import boto3
print(boto3.client('sts').get_caller_identity())

返回结果的Arn字段即为当前执行身份的唯一标识：

• 若格式为arn:aws:iam::[账号ID]:user/[用户名]，说明当前操作用的是你的个人用户权限
• 若格式为arn:aws:iam::[账号ID]:role/[角色名]，说明当前操作用的是IAM角色权限

核心原因说明：image_uris.retrieve()方法默认不会自动读取get_execution_role()返回的角色，会直接走当前环境的默认凭证链身份。XGBoost等内置算法的镜像检索逻辑绑定在Estimator初始化流程中，会自动使用传入的role对应权限，但JumpStart提供的LightGBM等算法的镜像检索逻辑独立于Estimator，默认使用本地凭证，这就是两者权限表现不一致的原因。

指定其他执行角色的实现方式 #

支持指定其他执行角色完成镜像拉取操作，核心逻辑是通过STS服务AssumeRole拿到目标角色的临时凭证，再用该凭证初始化独立的SageMaker Session传入检索方法即可，示例代码：

import boto3
import sagemaker
from sagemaker import image_uris

# 替换为get_execution_role()返回的SageMaker执行角色ARN
role_arn = sagemaker.get_execution_role()

# 获取目标角色的临时访问凭证
sts = boto3.client('sts')
cred = sts.assume_role(
    RoleArn=role_arn,
    RoleSessionName="jumpstart-pull"
)['Credentials']

# 用临时凭证初始化boto3会话
boto_sess = boto3.Session(
    aws_access_key_id=cred['AccessKeyId'],
    aws_secret_access_key=cred['SecretAccessKey'],
    aws_session_token=cred['SessionToken'],
    region_name="替换为你实际使用的区域，如us-east-1"
)
sess = sagemaker.Session(boto_session=boto_sess)

# 传入自定义会话调用镜像检索，此时操作将使用指定的执行角色权限
lgbm_uri = image_uris.retrieve(
    framework="lightgbm",
    region=sess.boto_region_name,
    version="替换为你需要的LightGBM版本",
    instance_type="替换为你实际使用的训练实例类型，如ml.m5.large",
    sagemaker_session=sess
)

后续初始化Estimator时直接传入拿到的lgbm_uri作为image_uri参数，搭配原来的role=get_execution_role()即可正常运行训练。

无AssumeRole权限的规避方案 #

如果你的用户账号没有AssumeRole到SageMaker执行角色的权限，可选择以下两种方案：

• 硬编码镜像URI：联系同账号下有权限的管理员/用户，在同区域执行一次上述镜像检索代码拿到固定的LightGBM镜像URI，直接将该字符串作为image_uri参数传入Estimator即可。JumpStart的官方镜像由AWS托管在账号共享的ECR仓库中，只要Estimator绑定的执行角色有ECR拉取权限就能正常启动训练，不需要你的个人账号有镜像检索相关权限。
• 申请最小权限补充：向管理员申请给你的用户账号补充JumpStart镜像元数据读取的最小权限，不需要开放S3存储桶创建权限，仅需对JumpStart官方存储元数据的S3路径开放s3:GetObject权限即可，权限范围可控，符合严格管控要求。

内容的提问来源于stack exchange，提问作者aa_imran