1

I'm new to the AWS ecosystem and have what might be a naive question. While trying to create a GlueRunner Lambda stack with CloudFormation (using pynt), from the Cloud9 shell of an account with all the relevant permissions set up through IAM, CloudWatch showed me an error that occurred because I was using a "truncated" ARN without the region and the account ID:

[ERROR] InvalidArn: An error occurred (InvalidArn) when calling the GetActivityTask operation: Invalid Arn: 'Invalid ARN prefix: GlueRunnerActivity'

In a different CI/CD pipeline, however, I had used the truncated pattern, and it had worked without issues. Specifically, I had used "executionRoleArn": "ecsTaskExecutionRole" in the task definition config JSON in a pipeline to deploy a docker image with ECS using GitHub Actions with access to the required access key ID and secret access key through the repository Secrets.

Is there a way to use a pattern similar to the latter, which does not disclose the account ID, in the former workflow?

strangeloop
  • 111
  • 1

1 Answers1

1

Your concern about obscuring your account ID is as valid as guarding your personal email address: if someone is trying to hack you, they could use your account id or email address to profile you or try and gain direct access to your account in a malicious way.

However, unmasked ARNs are ubiquitous within AWS (especially CLI inputs, outputs and CloudWatch logs). There is no easy way to automatically obscure them everywhere, and so far, AWS has not suggested we do this as a security best practice. They imply having unmasked ARNs in the logs is normal and needed for audits, troubleshooting, etc.

So the answer is: its a risk that you must mitigate as you see fit.

AWS does offer by default CloudWatch log encryption. They also advise a shared responsibility model when it comes to log security and suggest you can take further steps: like encryption with your own keys, doing regular key rotations, MFA depending on your risk assessment.

Reference to similar questions on devops and infosec.

Taterhead
  • 158
  • 5