Skip to main content

AWS

Visualize AWS cloud resources, map AWS users to employees, and monitor visibility, governance, and compliance against the AWS CIS Framework and security benchmarks. Additionally, monitor AWS vulnerabilities and findings and changes in AWS cloud resources through queries and alerts.

Installation​

To install this integration, you will need to configure settings both within AWS and on JupiterOne. The integration instance configuration requires the customer's Role ARN to assume in order to read infrastructure information through AWS APIs. The role is configured to require an External ID; this value is auto-generated by JupiterOne and must be used when creating the IAM role.

By default, information is ingested from every region enabled on the AWS account, except regions that require additional contractual arrangements with AWS. You can narrow the set of regions ingested with the Included AWS regions and Excluded AWS regions options, described under Region Selection. Submit a JupiterOne support request if you need to monitor additional regions.

info

This integration enables the creation of automated workflows within JupiterOne alerts using SNS and SQS to remediate configuration gaps in AWS.

Configuration on AWS​

Detailed setup instructions and a pre-built CloudFormation Stack are provided in the application and maintained in the public JupiterOne AWS CloudFormation project on GitHub. Follow the steps under In JupiterOne to capture the auto-generated External ID specific to the integration instance.

Once the steps on GitHub are completed, continue to finalizing the integration instance on JupiterOne.

Configuration in JupiterOne​

To install the AWS integration in JupiterOne, navigate to Integrations and select AWS. Click New Instance to begin configuring the integration.

Creating an integration instance requires the following:

  • The Account Name used to identify the AWS account in JupiterOne. Ingested entities will have this value stored in tag.AccountName when the AccountName toggle is enabled.
  • A Description to assist in identifying the integration instance, if desired.
  • A Polling Interval that fits your monitoring needs. You may leave this as DISABLED and manually execute the integration.
  • The Role ARN of the IAM role to assume in order to authenticate with AWS.
  • The External ID associated with the IAM role. This value is auto-generated and should be used when creating the IAM role for this integration.

Click Create once all values are provided.

Use Role Chaining​

Enable Use Role Chaining to cause the integration to assume an intermediate IAM role before assuming the primary Role ARN. This gives AWS administrators a dedicated role to monitor and audit the actions taken by this integration.

When Use Role Chaining is enabled, two additional required fields appear:

  • Intermediate Role ARN — The ARN of the IAM role to assume before assuming the primary Role ARN.
  • Intermediate External ID — The External ID associated with the intermediate role.

Set Permissions​

The AWS integration requires security auditor permissions into the target AWS account, as defined by a combination of the SecurityAudit IAM policy managed by AWS, and a few additional List*, Get*, and Describe* permissions missing from the AWS managed policy. The exact policy and permission statements can be found in the public JupiterOne AWS CloudFormation project on GitHub.

Amazon Keyspaces​

The CloudFormation templates don't grant cassandra:Select. Amazon Keyspaces authorizes reading table metadata with Select on the table itself, which also allows reading the table's data. If you enable the Amazon Keyspaces and Amazon Keyspaces Tables data sources, add this statement to the role, optionally limiting the last two resources to the keyspaces and tables you want to ingest:

{
  "Effect": "Allow",
  "Action": "cassandra:Select",
  "Resource": [
    "arn:aws:cassandra:*:*:/keyspace/system*",
    "arn:aws:cassandra:*:*:/keyspace/*/",
    "arn:aws:cassandra:*:*:/keyspace/*/table/*"
  ]
}

Manage Organization Accounts​

After configuring the AWS integration, enable Configure Organization Accounts to automatically create and manage JupiterOne integration instances for all accounts in your AWS Organization. This account must be the management (master) account, and all accounts must share the same IAM role name and External ID.

To exclude a specific sub-account from automatic integration configuration, tag the sub-account in AWS Organizations with: j1-integration: SKIP.

When Configure Organization Accounts is enabled, two additional options become available:

  • Auto-delete Removed Accounts — When enabled, JupiterOne automatically deletes integration instances for AWS accounts that have been deleted or removed from the Organization. Enabled by default.
  • Auto-delete sub-accounts — When enabled, JupiterOne automatically deletes sub-account integration instances when the parent organizational account integration is deleted.
note

JupiterOne automatically ingests all sub-accounts from the Organization the next time it polls your environment.

Create the role in every account of the Organization​

JupiterOne assumes the role in each sub-account using the management account's role name, so the role must exist with exactly the same name in the management account and in every sub-account. Use the organization CloudFormation template for both steps below. It names the role from the JupiterOneRoleName parameter (default JupiterOne). The AWS Organization tab in the integration's Setup instructions shows the template URL for your JupiterOne region, along with the External ID and account ARNs to enter.

warning

Don't use the single-account template (the Launch CloudFormation stack button for a single account) in an Organization setup. It lets CloudFormation generate the role name, for example JupiterOneIntegration-JupiterOneRole-A1B2C3D4E5F6, and that name can never match the role in the other accounts.

Enter the External ID and JupiterOne AWS account ARNs shown in the Setup instructions of the new integration as the template parameters. The account ARNs depend on your JupiterOne region, so don't keep the template defaults.

  1. Sub-accounts: from the management account (or a delegated administrator), create a CloudFormation StackSet with the organization template and service-managed permissions, targeting your organization root or the OUs you want to monitor (from a delegated administrator, use --call-as DELEGATED_ADMIN with the AWS CLI). Deploy it to one Region only: IAM is global, so a second Region fails with "already exists". Enable automatic deployment so new accounts get the role. Service-managed StackSets require trusted access with AWS Organizations.
  2. Management account: AWS never deploys StackSet instances to the management account, even when you target the organization root (AWS documentation). Create a regular stack named JupiterOneOrganization in the management account with the same template and the same parameter values, including the role name. Don't name it JupiterOneIntegration: that's the single-account stack name, and creating a stack with a name that already exists fails.
  3. In JupiterOne: use the management account role ARN, for example arn:aws:iam::<management-account-id>:role/JupiterOne, and enable Configure Organization Accounts.

The AWS Organization tab in the integration's Setup instructions prefills these values and provides the AWS CLI commands for both steps.

If an account already has an IAM role named JupiterOne (for example, created manually), the stack fails with "already exists". Delete that role or set JupiterOneRoleName to another name, the same in every account.

If the management account already has the single-account stack (usually named JupiterOneIntegration), keep it while you set up the organization: its role has a generated name, so it doesn't conflict with the JupiterOne role, and the JupiterOneOrganization stack has a different name. Delete the old stack once the integration uses the new role ARN.

When adding or configuring sub-accounts separately, use the same IAM role name, policies, and External ID as the management account.

Service Control Policy Issues​

Errors may occur if a Service Control Policy (SCP) is blocking specified services or regions. AWS services that JupiterOne cannot ingest are listed in the Integration Jobs logs (Integrations > Configurations > Settings > Jobs).

For each SCP that is blocking JupiterOne ingestion, add the following condition to your SCP JSON:

"Condition": {
  "ArnNotLike": {
    "aws:PrincipalARN": [
        "arn:aws:iam::*:role/JupiterOne*"
    ]
  }
}

Ensure this ARN matches the IAM role ARN used to configure your JupiterOne AWS integration.

info

See the AWS Service control policies documentation for the latest information.

Data Volume Configuration​

Control how much data is ingested from AWS to manage storage and processing volume.

Ingestion Windows​

FieldDescriptionDefaultOptions
ECR Image Findings Ingestion WindowIngestion window for ECR image findings. Findings for images pulled or pushed within this timeframe are collected.7 days1 day, 3 days, 7 days, 30 days, 90 days
Inspector V2 Findings Ingestion WindowIngestion window for Inspector V2 findings observed within the selected timeframe.30 days7 days, 30 days, 60 days, 90 days
Security Hub Findings Ingestion WindowIngestion window for Security Hub findings. Only findings updated within this timeframe are collected. Leave empty to collect all active findings regardless of age.30 days7 days, 30 days, 60 days, 90 days

Longer windows increase the number of security findings ingested from ECR, Inspector, and Security Hub.

Region Selection​

By default, JupiterOne ingests from every region enabled on the AWS account. Use these options to limit ingestion to a subset of regions.

FieldDescriptionDefault
Included AWS regionsOpt in to a subset of AWS regions. When no region is selected, every region enabled on the AWS account is ingested. Regions that are not enabled on the account are skipped even when selected.None (all enabled regions)
Excluded AWS regionsOpt out of specific AWS regions. Applied after the included regions selection.None (no regions excluded)

Data Filtering Options​

FieldDescriptionDefaultOptions
ECR Findings SeveritiesSelect which severity levels of ECR image findings to ingest.All severitiesInformational, Low, Medium, High, Critical
ECR Findings Maximum Scan AgeSkip ECR image findings from scans completed more than the selected number of days ago. Findings without a scan completion date are always ingested.All ages30 days, 90 days, 180 days, 365 days
Inspector V2 resource typesLimit Inspector V2 findings to specific AWS resource types.All typesAWS EC2 Instance, AWS ECR Container Images, AWS ECR Repository, AWS Lambda Function, AWS Code Repository
Inspector V2 finding severitiesSelect which severity levels of Inspector V2 findings to ingest.Critical, HighCritical, High, Medium, Low, Informational, Untriaged
Inspector V2 finding fix availabilityIngest only Inspector V2 findings with the selected fix availability.All findingsFix available, No fix available, Partial fix available
Security Hub compliance status to skipCompliance status values to exclude when ingesting Security Hub findings.None (all ingested)Passed, Warning, Failed, Not available
Security Hub workflow status to skipWorkflow status values to exclude when ingesting Security Hub findings. Skipping Resolved and Suppressed is a common way to reduce noise.None (all ingested)New, Notified, Resolved, Suppressed

Advanced Configuration​

FieldDescriptionDefault
Consent to Collect Sensitive DataWhen enabled, JupiterOne collects sensitive data from aws_lambda_function, aws_cloudformation_stack, aws_launch_template_version, and aws_ecs_task_definition entities. JupiterOne redacts most sensitive fields, but not environment variable names. If you store secrets in environment variables, consider enabling redaction.Enabled
Lambda Environment Variables To PromoteLambda environment variable names to promote as properties on aws_lambda_function entities (comma-separated). Values are not redacted — do not include variables that hold sensitive data.None
Ingest Backup Recovery Point TagsWhen enabled, JupiterOne fetches and attaches tags for AWS Backup recovery points. May increase integration run time.Disabled
Ingest EC2 deprecated imagesWhen enabled, JupiterOne ingests EC2 images that are deprecated. Deprecated images may contain less information and may increase integration run time.Disabled
Ingest Bedrock Agent InstructionsWhen enabled, JupiterOne ingests the system instruction (prompt) configured on Bedrock agents. This may contain sensitive business logic.Disabled

Reference​

S3 Bucket public Property​

The aws_s3_bucket.public property is calculated based on the Access field in the AWS S3 console:

Accessaws_s3_bucket.public
Publictrue
Objects can be publicundefined
Bucket and objects not publicfalse

AWS IAM Policies​

Each aws_iam_policy entity includes a boolean admin property that indicates whether the policy grants administrative-level access. The flag is determined from the policy name: if the name contains the word "admin" (case-insensitive), the flag is set to true. Examples: AdministratorAccess, AdminPolicy, MyCustomAdminRole.

Next Steps​

Now that your integration instance has been configured, it will begin running on the polling interval you provided, populating data within JupiterOne. See the Instance management guide to learn more about working with and editing integration instances.