|
1 |
| -# Compliance |
| 1 | +# Manually Onboard an AWS Account for CSPM |
2 | 2 |
|
| 3 | +To enable [CSPM (Compliance)](https://docs.sysdig.com/en/docs/sysdig-secure/posture/compliance/) in your AWS account, you create the following resources on the Sysdig Secure SaaS backend: |
3 | 4 |
|
4 |
| -## AWS |
5 |
| -On each account where compliance wants to be checked (`AWS_ACCOUNT_ID`), we need to provide a role for Sysdig to be able to impersonate and perform `SecurityAudit` tasks. |
| 5 | +- An `account` representing the AWS account for which you want to enable CSPM |
| 6 | +- A trust-relationship `component` that represents the IAM Role in your AWS account |
| 7 | +- A CSPM `feature` that indicates CSPM scans should be run against this account |
| 8 | + |
6 | 9 |
|
7 |
| -In addition, we must make Sysdig aware of these accounts and role. |
8 |
| -We will guide you to provide, on the Sysdig Secure SaaS backend, the following resources: |
9 |
| -- a cloud-account for each account of your organization where compliance is wanted to be checked |
10 |
| -- a task that will run `aws_foundations_bench-1.3.0` schema on previously defined accounts |
| 10 | +## Guidelines |
11 | 11 |
|
12 |
| -### Sysdig Side |
| 12 | +- This method of installation will only support CSPM (Compliance). |
13 | 13 |
|
14 |
| -1. **Register cloud accounts** on Sysdig |
| 14 | +- The following features will not work: |
| 15 | + - Threat Detection |
| 16 | + - Identity and Access |
| 17 | + - Image Scanning |
15 | 18 |
|
16 |
| -For each account you want to provision for the Compliance feature, we need to register it on Sysdig Secure, so |
17 |
| -it can impersonate and perform `SecurityAudit` tasks. |
| 19 | + To install other features, see the [Installation Guide](https://docs.sysdig.com/en/docs/installation/sysdig-secure/connect-cloud-accounts/aws/). |
| 20 | + |
| 21 | +- In each AWS account you want to run CSPM, you must create an IAM Role with `SecurityAudit` permissions that Sysdig is able to assume. |
| 22 | + |
| 23 | +- Ensure that you make Sysdig aware of these accounts and roles. |
| 24 | + |
| 25 | + |
| 26 | +## Preparation |
| 27 | + |
| 28 | +To learn more about using the Sysdig Secure APIs, see [Development Tools](https://docs.sysdig.com/en/docs/developer-tools/). |
| 29 | + |
| 30 | +### Retrieve the **Sysdig Trusted Identity** and **ExternalID** |
| 31 | + |
| 32 | +Run the following to retrieve the `TrustRelationshipPolicy`: |
18 | 33 |
|
19 |
| -For Sysdig Secure backend API communication [How to use development tools](https://docs.sysdig.com/en/docs/developer-tools/). Also, we have this [AWS provisioning script](./utils/sysdig_cloud_compliance_provisioning.sh) as reference, but we will explain it here too. |
20 | 34 | ```shell
|
21 |
| -$ curl "https://<SYSDIG_SECURE_ENDPOINT>/api/cloud/v2/accounts?upsert=true" \ |
22 |
| ---header "Authorization: Bearer <SYSDIG_SECURE_API_TOKEN>" \ |
23 |
| --X POST \ |
24 |
| --H 'Accept: application/json' \ |
25 |
| --H 'Content-Type: application/json' \ |
26 |
| --d '{ |
27 |
| - "accountId": "<AWS_ACCOUNT_ID>", |
28 |
| - "alias": "<AWS_ACCOUNT_ALIAS>", |
29 |
| - "provider": "aws", |
30 |
| - "roleAvailable": true, |
31 |
| - "roleName": "SysdigComplianceRole" |
32 |
| -}' |
| 35 | +$ curl -s 'https://<SYSDIG_SECURE_ENDPOINT>/api/cloud/v2/aws/trustedRoleDoc' \ |
| 36 | +--header 'Authorization: Bearer <SYSDIG_SECURE_API_TOKEN>' |
33 | 37 | ```
|
34 |
| -<br/> |
| 38 | +This policy will be used when you create an IAM role as given below. |
| 39 | + |
| 40 | +An example response to this call: |
| 41 | + |
| 42 | +```json |
| 43 | +{ |
| 44 | + "Version": "2012-10-17", |
| 45 | + "Statement": [ |
| 46 | + { |
| 47 | + "Effect": "Allow", |
| 48 | + "Principal": { |
| 49 | + "AWS": "arn:aws:iam::123456789012:role/us-east-1-some-sysdig-role" |
| 50 | + }, |
| 51 | + "Action": "sts:AssumeRole", |
| 52 | + "Condition": { |
| 53 | + "StringEquals": { |
| 54 | + "sts:ExternalId": "0123abc456defg7890hijk123lmn0774" |
| 55 | + } |
| 56 | + } |
| 57 | + } |
| 58 | + ] |
| 59 | +} |
| 60 | +``` |
| 61 | + |
| 62 | +## Provision Your AWS Account |
| 63 | + |
| 64 | +### Create an IAM Role |
| 65 | + |
| 66 | +Sysdig secures your cloud environment by assuming an IAM Role you create within your AWS Account. |
| 67 | + |
| 68 | +1. Create a new IAM Role with a Custom trust policy. |
| 69 | +2. Set the value of the trust polity to the `TrustRelationshipPolicy` policy retrieved above. |
| 70 | +3. Attach the AWS-managed `arn:aws:iam::aws:policy/SecurityAudit` policy. |
| 71 | +4. Give the role a unique name, and save the name for later use. |
| 72 | +5. Add **Tags** and a **Description** as desired. |
35 | 73 |
|
36 |
| -2. Register **Benchmark Task** |
| 74 | +For more information, see [IAM Roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) |
37 | 75 |
|
38 |
| -Create a single task to scope the organization account ids (or just a single account) to be assessed with the |
39 |
| -`aws_foundations_bench-1.3.0` compliance framework. |
| 76 | +## Provision Sysdig |
| 77 | + |
| 78 | +### Create an AWS Account Representation |
40 | 79 |
|
41 |
| -This script does not cover it, but specific regions can be scoped too. Check `Benchmarks-V2` REST-API for more detail |
42 | 80 | ```shell
|
43 |
| -$ curl -s "https://<SYSDIG_SECURE_ENDPOINT>/api/benchmarks/v2/tasks" \ |
| 81 | +$ curl "https://<SYSDIG_SECURE_ENDPOINT>/api/cloudauth/v1/accounts" \ |
44 | 82 | --header "Authorization: Bearer <SYSDIG_SECURE_API_TOKEN>" \
|
45 | 83 | -X POST \
|
46 | 84 | -H 'Accept: application/json' \
|
47 | 85 | -H 'Content-Type: application/json' \
|
48 | 86 | -d '{
|
49 |
| - "name": "Sysdig Secure for Cloud (AWS) - Organization", |
50 |
| - "schedule": "0 3 * * *", |
51 |
| - "schema": "aws_foundations_bench-1.2.0", |
52 |
| - "scope": "aws.accountId in ('<AWS_ACCOUNT_ID_1>',...,'<AWS_ACCOUNT_ID_N>')'", |
| 87 | + "providerId": "<AWS_ACCOUNT_ID>", |
| 88 | + "provider": "PROVIDER_AWS", |
53 | 89 | "enabled": true
|
54 | 90 | }'
|
55 | 91 | ```
|
56 | 92 |
|
57 |
| -<br/> |
58 |
| -
|
59 |
| -3. Get **Sysdig Federation Trusted Identity** |
60 |
| -
|
61 |
| -For later usage, fetch the Trusted Identity `SYSDIG_AWS_TRUSTED_IDENTITY_ARN` |
62 |
| -
|
63 |
| -```shell |
64 |
| -$ curl -s 'https://<SYSDIG_SECURE_ENDPOINT>/api/cloud/v2/aws/trustedIdentity' \ |
65 |
| ---header 'Authorization: Bearer <SYSDIG_SECURE_API_TOKEN>' |
66 |
| -``` |
67 |
| -
|
68 |
| - Response pattern: |
69 |
| -```shell |
70 |
| -arn:aws:iam::SYSDIG_AWS_ACCOUNT_ID:role/SYSDIG_AWS_ROLE_NAME |
| 93 | +An example response to this call: |
| 94 | + |
| 95 | +```json |
| 96 | +{ |
| 97 | + "id": "2fb94253-3a93-4d43-a739-2cb8c1c6f886", |
| 98 | + "customerId": "123", |
| 99 | + "enabled": true, |
| 100 | + "providerId": "123456789012", |
| 101 | + "provider": "PROVIDER_AWS", |
| 102 | + "feature": {}, |
| 103 | + "createdAt": "2023-05-22T21:26:03.288075Z", |
| 104 | + "updatedAt": "2023-05-22T21:26:03.288358Z" |
| 105 | +} |
71 | 106 | ```
|
72 | 107 |
|
73 |
| -<br/> |
| 108 | +Take note of the `id` field, which is referenced in subsequent calls. Note this is **not the AWS AccountID**, which is stored in the `providerId` field. |
74 | 109 |
|
75 |
| -4. Get **Sysdig ExternalId** |
76 | 110 |
|
77 |
| -For later usage, fetch `SYSDIG_AWS_EXTERNAL_ID` from one of the previously registered GCP accounts. All accounts will have same id (you only need to run it once). |
78 |
| -```shell |
79 |
| -$ curl -s "https://<SYSDIG_SECURE_ENDPOINT>/api/cloud/v2/accounts/<AWS_ACCOUNT_ID>?includeExternalId=true" \ |
80 |
| ---header "Authorization: Bearer <SYSDIG_SECURE_API_TOKEN>" |
81 |
| -``` |
82 |
| -From the resulting payload get the `externalId` attribute value, it should be a 32character string mixed with letters and numbers with no dashes, ex.:`0ab697b38dec8fb0932903jasfh38309` |
| 111 | +### Create a Trust Relationship Component |
83 | 112 |
|
84 |
| -<br/> |
| 113 | +1. Collect the following: |
85 | 114 |
|
86 |
| -### Customer's Side |
| 115 | + - `<CLOUD_ACCOUNT_ID>`: The `id` field retrieved from the response in the previous step. |
| 116 | + - `<ROLE_NAME>`: The name of the IAM role created above. Note this is not the ARN, but the role name. |
87 | 117 |
|
88 |
| -Now create `SysdigCompliance` role on each account using the values gathered in previous step. |
89 |
| - - Add `arn:aws:iam::aws:policy/SecurityAudit` AWS managed policy |
90 |
| - - Allow following Trusted-Identity |
91 |
| - ```json |
92 |
| - { |
93 |
| - "Effect": "Allow", |
94 |
| - "Action": "sts:AssumeRole", |
95 |
| - "Principal": { |
96 |
| - "AWS": [ "<SYSDIG_AWS_TRUSTED_IDENTITY_ARN>" ] |
97 |
| - }, |
98 |
| - "Condition": { |
99 |
| - "StringEquals": {"sts:ExternalId": "<SYSDIG_AWS_EXTERNAL_ID>"} |
100 |
| - } |
101 |
| - } |
102 |
| - ``` |
| 118 | +2. Replace `<CLOUD_ACCOUNT_ID>` and `<ROLE_NAME>` with the `id` and the role name respectively, and run the following: |
103 | 119 |
|
104 |
| -### End-To-End Validation |
| 120 | + ```shell |
| 121 | + $ curl -s "https://<SYSDIG_SECURE_ENDPOINT>/api/cloudauth/v1/accounts/<CLOUD_ACCOUNT_ID>/components" \ |
| 122 | + --header "Authorization: Bearer <SYSDIG_SECURE_API_TOKEN>" \ |
| 123 | + -X POST \ |
| 124 | + -H 'Accept: application/json' \ |
| 125 | + -H 'Content-Type: application/json' \ |
| 126 | + -d '{ |
| 127 | + "type": "COMPONENT_TRUSTED_ROLE", |
| 128 | + "instance": "manual", |
| 129 | + "trustedRoleMetadata": { |
| 130 | + "aws": { |
| 131 | + "roleName": "<ROLE_NAME>" |
| 132 | + } |
| 133 | + } |
| 134 | + }' |
| 135 | + ``` |
105 | 136 |
|
106 |
| -Validate if Sysdig <-> Customer infra connection is properly made using [`/cloud/accounts/{accountId}/validateRole`](https://secure.sysdig.com/swagger.html#tag/Cloud/paths/~1api~1cloud~1v2~1accounts~1{accountId}~1validateRole/get) |
107 | 137 |
|
108 |
| -```bash |
109 |
| -$ https://<SYSDIG_SECURE_ENDPOINT>/api/cloud/v2/accounts/<AWS_ACCOUNT_ID>/validateRole \ |
110 |
| ---header 'Authorization: Bearer <SYSDIG_SECURE_API_TOKEN>' |
111 |
| -``` |
| 138 | +### Create a CSPM Feature Representation |
112 | 139 |
|
113 |
| -You should get success or the reason of failure. |
| 140 | +Replace `<CLOUD_ACCOUNT_ID>` with the `id` field you have retrieved before and run the following: |
114 | 141 |
|
| 142 | +```shell |
| 143 | +$ curl -s "https://<SYSDIG_SECURE_ENDPOINT>/api/cloudauth/v1/accounts/<CLOUD_ACCOUNT_ID>/feature/FEATURE_SECURE_CONFIG_POSTURE" \ |
| 144 | +--header "Authorization: Bearer <SYSDIG_SECURE_API_TOKEN>" \ |
| 145 | +-X PUT \ |
| 146 | +-H 'Accept: application/json' \ |
| 147 | +-H 'Content-Type: application/json' \ |
| 148 | +-d '{ |
| 149 | + "type": "FEATURE_SECURE_CONFIG_POSTURE", |
| 150 | + "enabled": true, |
| 151 | + "components": ["COMPONENT_TRUSTED_ROLE/manual"] |
| 152 | +}' |
| 153 | +``` |
115 | 154 |
|
116 |
| -### Testing |
| 155 | +## Verify the Installation |
117 | 156 |
|
118 |
| -Check within Sysdig Secure |
119 |
| -- Posture > Compliance for the compliance task schedule |
120 |
| -- [Official Docs Check Guide](https://docs.sysdig.com/en/docs/installation/sysdig-secure-for-cloud/deploy-sysdig-secure-for-cloud-on-aws/#confirm-the-services-are-working) |
| 157 | +Verify that your installation is successful by following the [CSPM Validation instructions](https://docs.sysdig.com/en/docs/installation/sysdig-secure/connect-cloud-accounts/aws/#check-cspm). |
0 commit comments