跨AWS账号访问Kinesis流时遇Access Denied错误求助

核心错误分析 #

你的问题出在代码逻辑错误和配置与代码的不匹配上，具体如下：

一、代码层面的关键错误 #

1. 错误扮演自身账号角色
   代码中assumeRole变量使用的是sink账号自身的角色ARN，完全没有去扮演source账号中授权Kinesis访问的角色。这导致请求始终以sink账号的身份发起，根本没用到source账号的权限配置，自然会被拒绝。

2. 硬编码用户密钥的违规操作
   在Lambda函数中硬编码IAM用户的Access Key/Secret Key违反AWS最佳实践，Lambda应使用自身的执行角色凭证（SDK会自动获取），无需手动指定密钥。

二、配置与代码的不匹配问题 #

你在sink账号配置了允许扮演source账号角色的权限，也在source账号配置了信任sink账号的策略，但代码完全没有执行"扮演source账号角色"这个关键步骤，所有跨账号配置都未生效。

修复方案 #

1. 代码修复 #

移除硬编码密钥，修改角色扮演逻辑，改为扮演source账号的Kinesis授权角色：

private static async Task ReadFromKinesisStream(ILambdaContext context)
{
    AmazonKinesisConfig config = new AmazonKinesisConfig();
    config.RegionEndpoint = Amazon.RegionEndpoint.USEast1;

    // 替换为source账号中拥有Kinesis访问权限的角色ARN
    var sourceAccountRoleArn = "<ARN for Kinesis Access Role on source account>";
    // 自定义会话名称，便于日志追踪
    var sessionName = "CrossAccountKinesisAccessSession";

    // 使用Lambda执行角色的默认凭证，无需硬编码密钥
    AssumeRoleAWSCredentials roleAwsCredentials = new AssumeRoleAWSCredentials(
        FallbackCredentialsFactory.GetCredentials(), 
        sourceAccountRoleArn, 
        sessionName);

    AmazonKinesisClient client = new AmazonKinesisClient(roleAwsCredentials, config);

    DescribeStreamRequest describeRequest = new DescribeStreamRequest();
    describeRequest.StreamARN = "arn:aws:kinesis:us-east-1:<source account ID>:stream/<Kinesis stream name>";

    DescribeStreamResponse describeResponse = await client.DescribeStreamAsync(describeRequest);
    // 后续业务逻辑...
}

2. 配置验证与调整 #

• 确认sink账号Lambda执行角色权限：确保该角色的权限策略包含sts:AssumeRole，且Resource指向source账号的Kinesis授权角色ARN（即你之前配置的sink账号中扮演source账号角色的策略，需挂载在Lambda执行角色上）。
• 确认source账号角色信任策略：确保信任策略中的Principal是sink账号的Lambda执行角色ARN，而非其他角色。
• 确认source账号Kinesis权限策略：检查Resource是否准确指向目标Kinesis流的ARN，Action列表是否覆盖业务需求。

原代码报错原因 #

原代码中，你用sink账号用户的凭证去扮演sink自己的角色，最终请求身份还是sink账号的角色，这个角色并未被source账号的Kinesis流授权访问，因此触发AccessDeniedException。

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