问题描述
在学习AWS生态系统时，尝试使用CloudFormation（使用pynt）创建一个GlueRunner Lambda堆栈。他在拥有经过IAM设置的所有相关权限的账户的Cloud9 shell中遇到了一个问题，CloudWatch显示了一个错误，因为他在使用“截断”的ARN时没有包含区域和账户ID：
[ERROR] InvalidArn: An error occurred (InvalidArn) when calling the GetActivityTask operation: Invalid Arn: 'Invalid ARN prefix: GlueRunnerActivity'
然而，在另一个CI/CD流水线中，他使用了截断模式，并且在不透露账户ID的情况下正常工作。具体来说，他在任务定义配置JSON中使用了“executionRoleArn”：“ecsTaskExecutionRole”，并在使用GitHub Actions部署带有ECS的Docker镜像时，通过存储库Secrets访问了所需的访问密钥ID和秘密访问密钥。
用户想知道是否有一种类似于后者的模式，可以在前一个工作流程中不透露账户ID。
解决方案
请注意以下操作可能存在版本差异或安全风险，务必谨慎操作。
方案1
在AWS中，ARN（Amazon资源名称）在许多地方都是不加密的，尤其是在CLI输入、输出和CloudWatch日志中。目前，AWS并没有建议我们将ARN自动遮蔽以作为安全最佳实践。他们认为在日志中使用未遮蔽的ARN对于审计、故障排除等是正常且必要的。
因此，答案是：这是一种风险，你必须根据自己的需求采取适当的风险缓解措施。
AWS默认提供了CloudWatch日志加密。他们还建议在日志安全性方面采取进一步措施，例如使用自己的密钥进行加密、定期密钥轮换，根据风险评估采取多因素身份验证等。
对于类似问题的参考，可以查看devops和infosec上的类似问题。
方案2
对于特定需求，可以考虑创建一个代理层，来间接访问需要保密的ARN。这需要根据具体情况来设计和实现，并确保代理层本身具备足够的安全性。
有时，为了避免直接在应用程序中暴露敏感信息，可以考虑创建一个代理层，间接访问需要保密的ARN。这需要根据具体情况来设计和实现，确保代理层本身具备足够的安全性。这样，应用程序不直接使用敏感ARN，而是通过代理层来获取所需的资源，从而减少了在应用程序中直接透露ARN的风险。
注意：这是一种通用的安全设计原则，具体的实施方式需要根据应用程序的架构和需求来定制。
总结
在AWS生态系统中，ARN的使用是常见且不遮蔽的。要避免在ARN中透露账户ID，可以采取一些安全措施，例如加密CloudWatch日志、使用自己的密钥进行加密、定期密钥轮换等。如果需要在应用程序中避免直接使用敏感ARN，可以考虑创建一个安全的代理层，来间接访问需要保密的ARN。