如何通过AWS CDK/CloudFormation正确配置Lambda层权限，允许同AWS组织内的远程账户访问？

我完全理解你现在的困扰——明明通过AWS CLI可以轻松生成带组织ID条件的Lambda层权限策略，让同组织内的所有账户都能访问，但用CDK或者CloudFormation尝试同样的配置时，要么生成的策略缺失关键的Condition语句，要么指定单个账户时只能限制到root用户，导致用自定义角色部署的CloudFormation堆栈触发403权限错误。下面我给你几个靠谱的解决方案：

方案1：使用CDK L1构造（CfnLayerVersionPermission）直接定义 #

CDK的L2构造（比如add_permission方法）可能存在逻辑判断的问题，当同时指定accountId="*"和organizationId时，没有正确生成aws:PrincipalOrgID的Condition。这时可以直接用对应CloudFormation资源的L1构造，它会严格按照参数生成策略：

比如用TypeScript的示例：

import { CfnLayerVersionPermission } from 'aws-cdk-lib/aws-lambda';

// 假设myLayerVersion是你已经创建的Lambda层版本对象
new CfnLayerVersionPermission(this, 'OrgLayerAccessPermission', {
  layerVersionArn: myLayerVersion.layerVersionArn,
  action: 'lambda:GetLayerVersion',
  principal: '*', // 允许所有主体，但通过Condition限制到组织内
  organizationId: 'o-xxxxxxxxxx', // 替换成你的AWS组织ID
  statementId: 'AllowOrgAccountsAccess' // 唯一的语句ID
});

这个构造会直接映射到CloudFormation的AWS::Lambda::LayerVersionPermission资源，正确生成带Condition的策略：

{
  "Effect": "Allow",
  "Principal": "*",
  "Action": "lambda:GetLayerVersion",
  "Resource": "arn:aws:lambda:us-east-1:123456789012:layer:my_lambda_layer:1",
  "Condition": {
    "StringEquals": {
      "aws:PrincipalOrgID": "o-xxxxxxxxxx"
    }
  }
}

方案2：升级CDK版本（如果偏好L2构造） #

如果你更倾向于用L2的add_permission方法，有可能是你使用的CDK版本存在bug，导致无法正确处理accountId="*"和organizationId的组合。尝试把你的aws-cdk-lib包升级到最新稳定版本，然后重新部署：

比如用npm升级：

npm update aws-cdk-lib

升级后再调用add_permission：

myLayerVersion.addPermission('AllowOrgAccess', {
  accountId: '*',
  organizationId: 'o-xxxxxxxxxx'
});

新版本的CDK应该能正确生成带Condition的策略。

方案3：用自定义资源（CustomResource）复刻CLI行为 #

如果上述方案都不行，你可以用CDK的自定义资源直接调用Lambda的API，完全复刻AWS CLI的add-layer-version-permission命令行为：

import { AwsCustomResource, AwsCustomResourcePolicy, PhysicalResourceId } from 'aws-cdk-lib/custom-resources';
import { PolicyStatement } from 'aws-cdk-lib/aws-iam';

// 创建自定义资源调用Lambda API
new AwsCustomResource(this, 'LayerOrgPermission', {
  policy: AwsCustomResourcePolicy.fromStatements([
    new PolicyStatement({
      actions: ['lambda:AddLayerVersionPermission', 'lambda:RemoveLayerVersionPermission'],
      resources: [myLayerVersion.layerVersionArn]
    })
  ]),
  onCreate: {
    service: 'Lambda',
    action: 'addLayerVersionPermission',
    parameters: {
      LayerName: 'my_lambda_layer',
      VersionNumber: myLayerVersion.version,
      StatementId: 'OrgAccessStatement',
      Action: 'lambda:GetLayerVersion',
      Principal: '*',
      OrganizationId: 'o-xxxxxxxxxx'
    },
    physicalResourceId: PhysicalResourceId.of('LayerOrgPermission')
  },
  onUpdate: {
    service: 'Lambda',
    action: 'addLayerVersionPermission',
    parameters: {
      LayerName: 'my_lambda_layer',
      VersionNumber: myLayerVersion.version,
      StatementId: 'OrgAccessStatement',
      Action: 'lambda:GetLayerVersion',
      Principal: '*',
      OrganizationId: 'o-xxxxxxxxxx'
    }
  },
  onDelete: {
    service: 'Lambda',
    action: 'removeLayerVersionPermission',
    parameters: {
      LayerName: 'my_lambda_layer',
      VersionNumber: myLayerVersion.version,
      StatementId: 'OrgAccessStatement'
    }
  }
});

这个方法会完全模拟CLI的调用，确保生成的策略和CLI创建的一致。

关于单个账户访问的补充说明 #

如果需要允许单个特定账户访问，不需要只指定arn:aws:iam::ACCOUNT_ID:root作为Principal。实际上，指定Principal: "arn:aws:iam::ACCOUNT_ID:root"已经允许该账户下的所有身份（包括你的CloudFormation假定角色）访问，因为root是账户的顶级身份，所有账户内的实体都继承其权限。如果还是遇到问题，检查一下该角色是否有lambda:GetLayerVersion的权限（不过资源策略已经允许的话，通常不需要额外的身份策略）。

内容来源于stack exchange