> For the complete documentation index, see [llms.txt](https://docs.veedna.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.veedna.com/sca360-flexible-deployment-for-data-center-cloud-integrated-environments/prerequisites.md).

# Prerequisites

Before deploying SCA360, you must set up essential AWS resources to ensure the CloudFormation stack can launch successfully and that SCA360 can scan container images and process metadata securely. This includes a VPC ID, a Subnet ID, a Key Pair for secure VM access, an Amazon S3 bucket to store metadata files generated by your CI/CD pipeline, and an IAM role policy assigned to the EC2 instance running SCA360.

&#x20;If you are deploying through Open Virtual Applicance (OVA), see [<mark style="color:$primary;">Deploying SCA360 through Open Virtual Applicance (OVA)</mark>](/sca360-flexible-deployment-for-data-center-cloud-integrated-environments/deploying-lineaje-sca360.md)<mark style="color:$primary;">.</mark>

<details>

<summary>Step 1: Create a Virtual Private Cloud Identifier (VPC ID) in AWS</summary>

A VPC is your own isolated network within AWS where you can launch resources like EC2 instances and databases. The VPC ID helps AWS and you identify which VPC a resource belongs to.&#x20;

To create a VPC ID in AWS:

1. Sign in to the [Amazon VPC console](https://console.aws.amazon.com/vpc/).
2. Navigate to **VPC** service.
3. Click **Create VPC**.
4. Choose **VPC only** or **VPC and more** (for subnets, route tables, etc.).
5. In the form that appears:
   * **Name tag**: Enter a name for your VPC (e.g., `MyVPC`).
   * **IPv4 CIDR block**: Enter a CIDR block (e.g., `10.0.0.0/16`).
   * **IPv6 CIDR block** (optional): Enter an IPv6 CIDR block.
   * **Tenancy**: Select tenancy type (e.g., `Default`).
6. Click **Create VPC**.
7. The VPC ID is displayed after creation (e.g., `vpc-0a1b2c3d4e5f67890`). You’ll choose this VPC ID during the SCA360 deployment process.

</details>

<details>

<summary>Step 2: Create a Subnet ID in AWS</summary>

A Subnet ID is a unique identifier for a Subnet within a VPC. A subnet divides your VPC into smaller segments. Each subnet resides in a specific Availability Zone and can be public (internet-facing) or private (internal only).&#x20;

To create a Subnet ID in AWS:

1. In the **VPC Dashboard**, select **Subnets**.
2. Click **Create subnet**.
3. In the configuration window:
   * **VPC ID:** Select the VPC you created earlier.
   * **Subnet name:** Enter a name for your subnet (e.g., `PublicSubnet`).
   * **Availability Zone:** Choose an availability zone (e.g., `us-east-1a`).
   * **IPv4 CIDR block:** Enter a CIDR block (e.g., `10.0.1.0/24`).
4. Click **Create subnet**.
5. The **Subnet ID** is displayed after creation (e.g., `subnet-1234abcd`). You’ll choose this Subnet ID during the SCA360 deployment process

</details>

<details>

<summary>Step 3: Create a Key Pair in AWS</summary>

A Key Pair is a combination of a public key and a private key used for secure access to EC2 instances. When you launch an EC2 instance, you associate it with a key pair. The private key (stored by you) is used to SSH into the instance, while AWS keeps the public key.&#x20;

To create a Key Pair in AWS:

1. Navigate to the [**Amazon** **EC2**](https://console.aws.amazon.com/ec2/) service.
2. In the left-side navigation, click **Key Pairs**.
3. Click **Create key pair**.
4. In the configuration window:
   * **Key pair name:** Enter a name for your key pair (e.g., `MyKeyPair`).
   * **Key pair type:** Select a type (e.g., `RSA`).
   * **Private key format:** Choose a format (e.g., `PEM`).
5. Click **Create key pair**.
6. AWS downloads the private key file (e.g., `my-keypair.pem`). You’ll choose this Key Pair during the SCA360 deployment process.

</details>

<details>

<summary>Step 4: Creating an S3 Bucket</summary>

Metadata files are uploaded in Amazon S3 bucket. You can create the bucket using the AWS Management Console or the AWS CLI.

### **Creating an S3 bucket in AWS**

To create an S3 bucket in AWS Management Console:

1. Sign in to the AWS Management Console and navigate to **S3**.
2. Click **Create Bucket**.
3. Enter a unique bucket name and select a region.
4. Configure optional settings:
   * **Block Public Access**: Enabled by default for security.
   * **Versioning** (optional): For retaining multiple object versions.
   * **Default Encryption**: Recommended for data protection.
5. Click **Create Bucket**.

### **Creating an S3 Bucket Using Command Line**

To create an S3 bucket using command line:

1. Open AWS CloudShell or your local terminal with AWS CLI configured.
2. Run the following command, replacing:

   * <mark style="color:red;">`<BUCKET_NAME>`</mark> with your bucket name
   * <mark style="color:red;">`<REGION>`</mark> with the AWS region

   `aws s3api create-bucket --bucket`` `<mark style="color:red;">`<BUCKET_NAME>`</mark>` ``--region`` `<mark style="color:red;">`<REGION>`</mark>` ``--create-bucket-configuration LocationConstraint=`` `<mark style="color:red;">`<REGION>`</mark>

</details>

<details>

<summary>Step 5: Configuring a Role Policy</summary>

After creating the bucket, assign a policy to the IAM Role of the VM running <mark style="color:$danger;">SCA360</mark> so it can read metadata files from the bucket.

1. Go to **EC2** > **Instances**, select the VM running SCA360, and click the **IAM Role** linked to the instance. Note the Role Name.
2. Open AWS CloudShell (must have admin access) and run the following command, replacing:
   * `<ROLE_NAME>` with the **IAM Role** name of the VM.
   * `<BUCKET_NAME>` with the name of the S3 bucket you created.

```
aws iam put-role-policy \
    --role-name <ROLE_NAME> \
    --policy-name LineajeVMS3MetafilereadAccess \
    --policy-document '{ 
        "Version": "2012-10-17", 
        "Statement": [ 
            { 
                "Effect": "Allow", 
                "Action": [
                    "s3:GetObject", 
                    "s3:ListBucket"
                ], 
                "Resource": [
                    "arn:aws:s3:::<BUCKET_NAME>", 
                    "arn:aws:s3:::<BUCKET_NAME>/*"
                ] 
            } 
        ] 
    }'
```

3. Verify the policy is attached:
   1. Go to **IAM** > **Roles** > `<ROLE_NAME>` > **Inline Policies**.
   2. Confirm that the policy name is listed and includes the correct permissions.
   3. To confirm access, log in to the VM and run: `aws s3 ls s3://<BUCKET_NAME>`. If the command returns the bucket contents (or an empty list if no files exist), the configuration is successful.

</details>

<details>

<summary>Step 6: Configuring ECR Access and Cross-Account Role</summary>

You must allow <mark style="color:$danger;">SCA360</mark> to pull and push container images from ECR across AWS accounts to ensure secure cross-account access for workflows such as image scanning and SBOM generation. To configure ECR access and cross-account role:

1. Go to **EC2** > **Instances** > **IAM Role** and select the VM running SCA360.
2. Click on the **IAM Role** link.
3. In the **Summary** section, copy the **ARN** code.
4. In the target AWS account, create a policy (for example, `LineajeCrossAccountAccessPolicy`) and paste the following JSON:

   ```
   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "ecr:GetAuthorizationToken",
           "ecr:BatchCheckLayerAvailability",
           "ecr:GetDownloadUrlForLayer",
           "ecr:BatchGetImage",
           "ecr:InitiateLayerUpload",
           "ecr:UploadLayerPart",
           "ecr:CompleteLayerUpload",
           "ecr:PutImage",
           "ecr:DescribeRepositories",
           "ecr:ListImages",
           "ecr:DescribeImages",
         ],
         "Resource": "*"
       }
     ]
   }
   ```
5. Create an IAM Role (for example, `LineajeCrossAccountAccessRole`) in the target account and use the following trust policy:

   ```
   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "AWS": "<TARGET_ROLE_ARN>"
         },
         "Action": "sts:AssumeRole"
       }
     ]
   }
   ```
6. Replace `<TARGET_ROLE_ARN>` with the ARN copied earlier.
7. Go to **IAM** > **Roles** in the target AWS account, and search for the role you created, `LineajeCrossAccountAccessRole`.
8. Open the role and verify the ARN is listed under the `“Principal”` section of the trust policy in the **Trust relationships** tab.
9. In the **Permissions tab** > **Add permissions** > **Attach policies**, search for `LineajeCrossAccountAccessRole` and click Attach Policies, then attach `LineajeCrossAccountAccessRole` to the role.
10. Confirm that the SCA360 VM can access ECR repositories and the required S3 bucket.

</details>

<details>

<summary>Step 7 (Optional): Configuring Secret Manager and Role</summary>

When integrating SCA360 with external services such as GitHub or other systems that require tokens or credentials, storing these secrets securely is critical. Instead of hardcoding tokens in scripts or configuration files, you can use AWS Secrets Manager to manage sensitive information. This approach ensures secure retrieval by the SCA360 VM during automated workflows. To enable this, you must create a secret in Secrets Manager and grant the VM’s IAM role permission to read it.

1. Go to **AWS Secrets Manager** in the AWS account where the Lineaje Scanner VM is deployed.
2. Click **Store a new secret**.
3. Select **Other type of secret** and enter the key-value pair for the token (for example: `github_token: <your-token>`).
4. Click **Next**. Provide a descriptive name for the secret (for example: `SCA360/GitHubToken`) and complete the wizard.
5. Copy the **Secret ARN** after the secret is created.
6. Go to **EC2** > **Instances**, select the VM running SCA360, and click the **IAM Role** linked to the instance.
7. Note the **Role Name** associated with the VM.
8. Open a terminal or AWS CLI in the same AWS account and run the following command, replacing:
   * `<ROLE_NAME>` with the IAM Role name of the VM.
   * `<SECRET_ARN>` with the ARN of the secret created in Secrets Manager.

     ```
     aws iam put-role-policy \
         --role-name <ROLE_NAME> \
         --policy-name LineajeVMSecretReadAccess \
         --policy-document '{ 
             "Version": "2012-10-17", 
             "Statement": [ 
                 { 
                     "Effect": "Allow", 
                     "Action": [
                         "secretsmanager:GetSecretValue",
                         "secretsmanager:DescribeSecret"
                     ], 
                     "Resource": "<SECRET_ARN>"
                 } 
             ] 
         }'
     ```
9. Go to **IAM** > **Roles** > `<ROLE_NAME>` > **Inline Policies** and confirm that the policy `LineajeVMSecretReadAccess` is attached with the correct permissions.

</details>

<details>

<summary>Step 8 (Optional) Configuring GitHub Permissions</summary>

GitHub permissions are required if you plan to enable automated workflows that interact with GitHub repositories. For example, pulling source code for Software Composition Analysis (SCA) or uploading SBOM results. Configuring a fine-grained personal access token ensures secure integration while granting only the necessary permissions.

1. In your Github account, go to **Developer Settings** > **Personal access tokens** > **Fine-grained tokens**.
2. Click **Generate new token**.
3. In the configuration window:
   * **Token name**: Enter a name for the token.
   * **Expiration**: Select an expiration for the token.
   * **Resource owner**: Select a resource owner. The token will only be able to access resources owned by the selected resource owner.
   * **Repository access**: Select which repositories you want the token to access.
   * **Permissions**: Select the following permissions to grant to the token.
     * Contents (read, write)
     * Pull Requests (read, write)
     * Metadata (read)
     * Click Generate token.

</details>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.veedna.com/sca360-flexible-deployment-for-data-center-cloud-integrated-environments/prerequisites.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
