Community
Questions Library
Docs
Blog
Events
Swag
Github
Slack
JupiterOne
Discussions
Release Notes
Contact Us
AWS FAQs - AskJ1 Community
<main> <article class="userContent"> <p>[TOC]</p> <h2 data-id="some-of-my-aws-resources-seem-to-be-missing-from-the-asset-inventory-graph-what-is-going-on">Some of my AWS resources seem to be missing from the Asset Inventory / Graph. What is going on?</h2> <p>This is most commonly caused by incorrect or insufficient permissions. Check the IAM policy assigned to the IAM role used by JupiterOne in your AWS account. You can find details on the required permissions by going to <strong>Integrations Configuration</strong> > <strong>Add AWS Configuration</strong> > and clicking on the <strong>Setup Instructions</strong> button.</p> <p>Or they can be found on the <a rel="nofollow" href="https://github.com/JupiterOne/jupiterone-aws-cloudformation">jupiterone-aws-integration</a> project on Github.</p> <h2 data-id="how-can-i-add-or-configure-all-the-sub-accounts-in-my-aws-organization">How can I add or configure all the sub-accounts in my AWS Organization?</h2> <p>First configure your AWS Organization master account to JupiterOne per the instructions in the JupiterOne application or those found at the <a rel="nofollow" href="https://github.com/JupiterOne/jupiterone-aws-cloudformation">jupiterone-aws-integration</a> project on Github. During this process you will create an IAM Role for JupiterOne with specific policies attached and a specific external trust ID. Please note the IAM Role name, policies, and external trust ID used. Do not select the option "Auto-configure additional integrations..." yet.</p> <p>Now use your favorite infrastructure-as-code method to systematically generate an identical JupiterOne IAM Role in each of your sub-accounts. Be sure to name the IAM Role identically, attach the same policies, and use the same external trust ID as was used with the master account configuration.</p> <p>Finally, make sure that in the JupiterOne application you have selected a polling interval and select the option to "Auto-configure additional integrations..." in your master account configuration.</p> <p>If these steps are done correctly, JupiterOne will automatically pull in all sub-accounts from the Organization the next time it polls your environment.</p> <h2 data-id="how-can-i-skip-certain-sub-accounts-when-auto-configuring-my-aws-organization">How can I skip certain sub-accounts when auto-configuring my AWS Organization?</h2> <p>To skip certain sub-accounts when auto-configuring JupiterOne AWS integrations from an Organizations master account, add the optional <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">j1-integration: SKIP</code> tag to the sub-account in your infrastructure-as-code or from the AWS Organizations web console.</p> <h2 data-id="how-can-i-bypass-a-service-control-policy-blocking-the-jupiterone-integration">How can I bypass a Service Control Policy blocking the JupiterOne Integration?</h2> <p>See the <a rel="nofollow" href="https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html">AWS Service control policies documentation</a> for the latest information.</p> <p>Errors may occur after configuring one or many AWS integrations if there is a Service Control Policy (SCP) blocking specified services or regions. Any AWS Services that cannot be ingested by JupiterOne can be found within the logs of the <em>Integration Jobs</em> (Integrations > Configurations > Settings > Jobs).</p> <p><img src="https://us.v-cdn.net/6035534/uploads/FRO4X41TBU51/faq-integration-jobs.png" alt="Integration Jobs" class="embedImage-img importedEmbed-img"></img></p> <p>For each SCP that is blocking JupiterOne ingestion, add the following condition element to your SCP JSON:</p> <p><strong>Note</strong>: Make sure the ARN below matches the IAM Role ARN you used to configure your JupiterOne AWS integration.</p> <pre class="code codeBlock" spellcheck="false" tabindex="0">"Condition": { "ArnNotLike": { "aws:PrincipalARN": [ "arn:aws:iam::*:role/JupiterOne*" ] } } </pre> <h2 data-id="i-have-a-network-marked-as-public-what-does-that-mean">I have a Network marked as "public", what does that mean?</h2> <p>The <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">public</code> property on a Network entity means the network is publicly accessible. A publicly accessible network could be either internal or external. There is an <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">internal</code> property to indicate whether that is the case.</p> <p>A network that is not an entity ingested from an integration is determined to be potentially an external network, with <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">internal=undefined</code>. When such a network (or host) has a public IP address or CIDR, it is set to be <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">public=true</code>.</p> <p>An internal network - that is, a Network entity ingested from an integration, such as an <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">aws_subnet</code> or <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">aws_vpc</code> - is set to <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">internal=true</code>. An internal network may be determined to be publicly accessible by the integration with certain conditions that are specific to each type of integration.</p> <h2 data-id="how-is-it-determined-if-an-aws-vpc-or-subnet-is-public">How is it determined if an AWS VPC or Subnet is public?</h2> <p>An <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">aws_vpc</code> or <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">aws_subnet</code> is determined to be publicly accessible -- i.e. <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">public=true</code> -- only when the following conditions are met:</p> <ul><li>The VPC has an Internet Gateway that connects it to the Internet</li> <li>The VPC or subnet has a Route in the Route Table to external networks</li> <li>The VPC or subnet has a Network ACL that allows traffic to/from external networks</li> </ul><h2 data-id="why-is-the-security-group-of-an-ec2-instance-showing-as-connected-to-the-internet-when-the-instance-itself-is-not-in-a-public-subnet">Why is the security group of an EC2 instance showing as connected to the Internet when the instance itself is not in a public subnet?</h2> <p>Relationships in the JupiterOne graph represent the actual configurations between two entities.</p> <p>In this case, if a security group has a rule allowing traffic to or from the Internet, there will be a relationship edge between that security group connecting it to/from the Internet. The EC2 instance itself will <em>not</em> have a relationship edge to/from the Internet.</p> <p>To determine whether an EC2 instance is publicly accessible, the instance itself needs to be in a public subnet in addition to having a security group rule allowing traffic. This is determined by a query that checks for both of these conditions:</p> <pre class="code codeBlock" spellcheck="false" tabindex="0">Find aws_subnet with public=true that HAS aws_instance that PROTECTS aws_security_group that ALLOWS Internet Return tree </pre> <h2 data-id="how-do-i-add-custom-properties-to-my-aws-entities-from-the-source">How do I add custom properties to my AWS entities from the source?</h2> <p>You can add custom properties by tagging your AWS resources. AWS supports tags for most resources. All tags will be ingested as entity properties. Each tag will have a prefix <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">tag.</code> followed by the tag name as the entity property name.</p> <p>You can then build queries using these tag properties. For example:</p> <pre class="code codeBlock" spellcheck="false" tabindex="0">Find aws_instance with tag.Environment='staging' </pre> <h2 data-id="i-am-using-a-powerful-policy-like-administratoraccess-in-aws-why-can-t-i-query-on-the-resources-it-allows">I am using a powerful policy like AdministratorAccess in AWS, why can't I query on the resources it allows?</h2> <p>The relationships in J1 are built between the entities as described in the environments. For example, the <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">AdministratorAccess</code> IAM policy in AWS has an <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">allow *:*</code> rule, therefore, a relationship is built directly from that <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">aws_iam_policy</code> entity to the <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">aws_account</code> entity.</p> <p>Similarly, if the policy states <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">allow s3:*</code>, the <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">ALLOWS</code> relationship in JupiterOne is built between the <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">aws_iam_policy</code> entity to the <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">aws_s3</code> service entity. This approach allows for simpler graph without thousands of connections from one entity to all other sub-entities that reside within an account or service.</p> <p>These conditions need to be taken into account at the query level.</p> <p>For example, to find IAM policies that allow access to S3 buckets, we should also check those that allow access to all resources in the S3 service and those that allow access to all services in the AWS account.</p> <p>This is done simply as follows:</p> <pre class="code codeBlock" spellcheck="false" tabindex="0">Find AccessPolicy that ALLOWS (aws_account|aws_s3|aws_s3_bucket) ... </pre> <h2 data-id="how-do-i-check-the-status-of-s3-server-access-logging-vs-bucket-object-logging">How do I check the status of S3 server access logging vs bucket object logging?</h2> <p>To check logging status specifically for <strong>Server Access Logging</strong>:</p> <pre class="code codeBlock" spellcheck="false" tabindex="0">Find aws_s3_bucket that logs to aws_s3_bucket return tree </pre> <p>To check logging status specifically for <strong>Object Level Logging</strong>:</p> <pre class="code codeBlock" spellcheck="false" tabindex="0">Find aws_s3_bucket that sends aws_cloudtrail that logs to * return TREE </pre> <p><strong>Note:</strong><br> Object level logging is done via CloudTrail</p> <p>To check for if a bucket does not have any logging enabled:</p> <pre class="code codeBlock" spellcheck="false" tabindex="0">Find aws_s3_bucket with loggingEnabled != true </pre> <p><strong>Note:</strong><br> Either server access logging or object level logging will result in <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">loggingEnabled = true</code></p> <p><strong>Bonus:</strong> to check for S3 buckets that publish <strong>inventory reports</strong>:</p> <pre class="code codeBlock" spellcheck="false" tabindex="0">find aws_s3_bucket that publishes to aws_s3_bucket return tree </pre> <p><strong>Note:</strong><br> There are additional properties captured on the edge in each case, which can be used for additional filtering (see screenshots).</p> <pre class="code codeBlock" spellcheck="false" tabindex="0">For example: ```j1ql find aws_s3_bucket that sends aws_cloudtrail that logs to * where logs.read=true and logs.write=true return TREE ``` </pre> <h2 data-id="how-can-i-add-or-configure-all-the-sub-accounts-in-my-aws-organization-1">How can I add or configure all the sub-accounts in my AWS Organization?</h2> <p>First, configure your AWS Organization master account to JupiterOne, using the instructions in the J1 Integrations UI or those found in the <a rel="nofollow" href="https://github.com/JupiterOne/jupiterone-aws-cloudformation">jupiterone-aws-integration</a> project on Github. During this process, you create an IAM role for J1, attaching specific policies and using a specific external trust ID. Remember to note the IAM role name, policies, and external trust ID that you use. Do not select the <strong>Auto-configure additional integrations...</strong>option yet.</p> <p>Next, use your preferred infrastructure-as-code method to systematically generate an identical J1 IAM role in each of your sub-accounts. Ensure you name the IAM Role identically, attach the same policies, and use the same external trust ID as you used with the master account configuration.</p> <p>Finally, in the J1 Integrations UI, select a polling interval and the <strong>Auto-configure additional integrations...</strong> option in your master account configuration.</p> <p>Jupiter1 automatically ingests all sub-accounts from the Organization the next time it polls your environment.</p> <h2 data-id="how-can-i-omit-certain-sub-accounts-when-auto-configuring-my-aws-organization">How can I omit certain sub-accounts when auto-configuring my AWS Organization?</h2> <p>To omit specific sub-accounts when auto-configuring J1 AWS integrations from an Organizations master account, add the optional <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">j1-integration: SKIP</code> tag to the sub-account in your infrastructure-as-code or from the AWS Organizations web console.</p> <h2 data-id="why-do-some-of-my-aws-account-entities-only-show-accountid-and-displayname-properties">Why do some of my <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">aws_account</code> entities only show <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">accountId</code> and <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">displayName</code> properties?</h2> <p>These properties are very likely discovered <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">aws_account</code> entities that JupiterOne has identified as having relationships to your owned resources. You can confirm this by checking <a rel="nofollow" href="https://jupiterone.vanillacommunities.com/kb/articles/1036-entity-and-relationship-metadata">the metadata</a>. The <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">_source</code> property should be <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">system-mapper</code> for these entities instead of <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">integration-managed</code>. Because it is not an integrated <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">aws_account</code>, there are limited properties on the entity, but JupiterOne has identified that this foreign <code class="code codeInline code codeInline" spellcheck="false" tabindex="0">aws_account</code> has access to resources you do own (typically via trust relationships in your environment).</p> <p>For example, if an AWS account ID is referenced in an IAM policy or S3 bucket policy and that account ID does not match an account integrated with JupiterOne, a mapped entity is created to represent that AWS account with limited metadata.</p> </article> </main>
.png)