<p>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.</p>
<p>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.</p>
<p>So the answer is: <em>its a risk that you must mitigate as you see fit</em>.</p>
<p>AWS does offer by default CloudWatch log encryption.  They also advise a <a href="https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/data-protection.html" rel="nofollow noreferrer">shared responsibility model</a> 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.</p>
<p>Reference to similar questions on <a href="https://devops.stackexchange.com/questions/11101/should-aws-arn-values-be-treated-as-secrets">devops</a> and <a href="https://security.stackexchange.com/questions/192539/keeping-aws-account-id-secret">infosec</a>.</p>

CC BY-SA 4.0
2022-02-06T14:35:02.100Z
2022-02-06T17:18:19.730Z
2022-02-06T17:18:19.730Z
Taterhead
<p>I'm new to the AWS ecosystem and have what might be a naive question. While trying to create a <code>GlueRunner</code> <code>Lambda</code> stack with <code>CloudFormation</code> (using <code>pynt</code>), from the <code>Cloud9</code> shell of an account with all the relevant permissions set up through <code>IAM</code>, <code>CloudWatch</code> showed me an error that occurred because I was using a &quot;truncated&quot; <code>ARN</code> without the region and the account ID:</p>
<pre><code>[ERROR] InvalidArn: An error occurred (InvalidArn) when calling the GetActivityTask operation: Invalid Arn: 'Invalid ARN prefix: GlueRunnerActivity'
</code></pre>
<p>In a different CI/CD pipeline, however, I had used the truncated pattern, and it had worked without issues. Specifically, I had used <code>&quot;executionRoleArn&quot;: &quot;ecsTaskExecutionRole&quot;</code> in the task definition config JSON in a pipeline to deploy a docker image with <code>ECS</code> using <code>GitHub Actions</code> with access to the required access key ID and secret access key through the repository <code>Secrets</code>.</p>
<p>Is there a way to use a pattern similar to the latter, which does not disclose the account ID, in the former workflow?</p>

<amazon-web-services><aws-iam><aws-cloudformation><devsecops>
How to avoid disclosing account ID in AWS ARN
strangeloop
# How to avoid disclosing account ID in AWS ARN

(Asked by: username_0 on 2022-02-02)

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?

**Tags:** amazon-web-services, aws-iam, aws-cloudformation, devsecops


---

## 1 answers

### Answer by username_1 on 2022-02-06. Score: 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](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/data-protection.html) 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](https://devops.stackexchange.com/questions/11101/should-aws-arn-values-be-treated-as-secrets) and [infosec](https://security.stackexchange.com/questions/192539/keeping-aws-account-id-secret).


---

