|
| 1 | +# Secure for Cloud - Organizational Cloudtrail with S3 in a different account |
| 2 | + |
| 3 | +## Use-Case explanation |
| 4 | + |
| 5 | +**Current User Setup** |
| 6 | + |
| 7 | +- Secure for Cloud organizational setup, meaning |
| 8 | + - Management Account level AWS Organizational Cloudtrail |
| 9 | + - Cloudtrail has SNS activated |
| 10 | +- In this use-case, the S3 bucket is not in the management account of the organization, but on a different logging |
| 11 | + account |
| 12 | +- Compute cluster available (EKS or ECS) for Sysdig workload to deployment |
| 13 | +- Permission provisioning will be performed manually with several IAM Roles |
| 14 | + |
| 15 | +**Sysdig Secure for Cloud [Features](https://docs.sysdig.com/en/docs/installation/sysdig-secure-for-cloud/)** |
| 16 | +- Threat-Detection |
| 17 | +- Posture; Compliance + Identity Access Management |
| 18 | +<br/><br/> |
| 19 | + |
| 20 | +## Suggested building-blocks |
| 21 | + |
| 22 | +### 1. **Compliance setup** on Sysdig backend and AWS Accounts |
| 23 | + |
| 24 | +On each member-account where compliance wants to be checked, we need to provide a role for Sysdig to be able to impersonate and |
| 25 | +perform `SecurityAudit` tasks. |
| 26 | + |
| 27 | +In addition, we must make Sysdig aware of this accounts and role. |
| 28 | +We will guide you to provide, on the Sysdig Secure SaaS backend, the following resources: |
| 29 | +- a cloud-account for each member account of your organization where compliance is wanted to be checked |
| 30 | +- a task that will run "aws_foundations_bench-1.3.0" schema on previously defined accounts |
| 31 | + |
| 32 | +Perform the following steps. |
| 33 | +- 1.1 Provision Sysdig Secure SaaS Backend with the [sysdig_cloud_compliance_provisioning.sh](../../utils/sysdig_cloud_compliance_provisioning.sh) script. |
| 34 | + - Review and provide required values before launching |
| 35 | + - Gather `TrustIdentity` and `ExternalId` values. |
| 36 | +- 1.2 Now create `SysdigComplianceRole` on each member account, using [Sysdig Compliance IAM policy](../../general_templates/ComplianceAgentlessRole.yaml) as guidance |
| 37 | +and using the values gathered in previous step. |
| 38 | +<br/><br/> |
| 39 | + |
| 40 | +### 2. Prepare **EKS/ECS SysdigComputeRole** |
| 41 | + |
| 42 | +First let's review permission schema. |
| 43 | + |
| 44 | + |
| 45 | +In further steps, we will deploy Sysdig compute workload inside an EKS/ECS cluster. |
| 46 | + |
| 47 | +We are going to need a `SysdigComputeRole` (attached to the compute service), to configure some permissions to be |
| 48 | +able to fetch the required data. |
| 49 | + |
| 50 | +- for **EKS** cluster, create a `SysdigComputeRole` role for the IAM authentication setup mapping, or if you want to |
| 51 | + quickly test it, just make use of the `eks_nodes` role generated by default in EKS. |
| 52 | +- for **ECS** cluster create a `SysdigComputeRole`, with the Trust relationship to allow ECS-Task usage |
| 53 | + ``` |
| 54 | + { |
| 55 | + "Version": "2012-10-17", |
| 56 | + "Statement": [ |
| 57 | + { |
| 58 | + "Sid": "", |
| 59 | + "Effect": "Allow", |
| 60 | + "Principal": { |
| 61 | + "Service": "ecs-tasks.amazonaws.com" |
| 62 | + }, |
| 63 | + "Action": "sts:AssumeRole" |
| 64 | + } |
| 65 | + ] |
| 66 | + } |
| 67 | + ``` |
| 68 | + |
| 69 | +<br/><br/> |
| 70 | +### 3. **Cloudtrail SQS** |
| 71 | + |
| 72 | +In order to ingest cloudtrail events we will need a queue endpoint. |
| 73 | +Access your cloudtrail and activate SNS notification if it's not already available. |
| 74 | + |
| 75 | +Now **create** an SQS queue (in the same region as the SNS, and in the same account as where the EKS/ECS cluster is), and subscribe the SNS topic to it. |
| 76 | +Because these two resources (SNS and SQS) are in different account, you will need to give permissions in the SNS for |
| 77 | +the SQS to be able to `SNS:Subscribe` it. |
| 78 | +<!-- |
| 79 | + { |
| 80 | + "Sid": "Subscribe", |
| 81 | + "Effect": "Allow", |
| 82 | + "Principal": { |
| 83 | + "AWS": "*" |
| 84 | + }, |
| 85 | + "Action": "SNS:Subscribe", |
| 86 | + "Resource": "arn:aws:sns:eu-west-3:237944556329:irutest-3-cross-account" |
| 87 | + } |
| 88 | +--> |
| 89 | + |
| 90 | +If SQS and EKS/ECS cluster are within the same account, you will only need to give **permissions** to either |
| 91 | +SysdigCompute IAM role (`ARN_SYSDIG_COMPUTE_ROLE`) or SQS. |
| 92 | + |
| 93 | +[Otherwise, you will need to provide permissions for both](https://aws.amazon.com/premiumsupport/knowledge-center/sqs-accessdenied-errors/#Amazon_SQS_access_policy_and_IAM_policy) <br/> |
| 94 | +Use following snipped if required |
| 95 | +```txt |
| 96 | + { |
| 97 | + "Sid": "AllowSysdigProcessSQS", |
| 98 | + "Effect": "Allow", |
| 99 | + "Principal": { |
| 100 | + "AWS": "<ARN_SYSDIG_COMPUTE_ROLE>" |
| 101 | + }, |
| 102 | + "Action": [ |
| 103 | + "SQS:ReceiveMessage", |
| 104 | + "SQS:DeleteMessage" |
| 105 | + ], |
| 106 | + "Resource": "<ARN_CLOUTRAIL_SNS_SQS>" |
| 107 | + } |
| 108 | +``` |
| 109 | +<br/><br/> |
| 110 | + |
| 111 | +### 4. **Cross-Account Access Role** |
| 112 | + |
| 113 | +This step provisions a role for `SysdigComputeRole` be able to assume, and access resources outside the account, |
| 114 | +such as S3 buckets. |
| 115 | + |
| 116 | +Create a `SysdigS3AccessRole` and setup a Trust Relationship, for Sysdig Compute role to be able to assume it. |
| 117 | +``` |
| 118 | +{ |
| 119 | + "Sid": "AllowSysdigAssumeRole", |
| 120 | + "Effect": "Allow", |
| 121 | + "Principal": { |
| 122 | + "AWS": "<ARN_SYSDIG_COMPUTE_ROLE>" |
| 123 | + }, |
| 124 | + "Action": "sts:AssumeRole" |
| 125 | +} |
| 126 | +``` |
| 127 | +<br/><br/> |
| 128 | + |
| 129 | +### 5. **Cross-Account Access Setup for S3** |
| 130 | + |
| 131 | +In the previously created `SysdigS3AccessRole`, we're gonna enable it to acces the `ARN_CLOUDTRAIL_S3` bucket where the events are stored |
| 132 | +Give the following **permission** Statement |
| 133 | +``` |
| 134 | + { |
| 135 | + "Sid": "AllowSysdigReadS3", |
| 136 | + "Effect": "Allow", |
| 137 | + "Action": [ |
| 138 | + "s3:GetObject" |
| 139 | + ], |
| 140 | + "Resource": "<ARN_CLOUDTRAIL_S3>/*" |
| 141 | +} |
| 142 | +``` |
| 143 | + |
| 144 | + |
| 145 | +Now we will need to perform same **permissions setup on the S3 bucket**. Add following Statement to the **Bucket policy** |
| 146 | + |
| 147 | +```text |
| 148 | +{ |
| 149 | + "Sid": "AllowSysdigReadS3", |
| 150 | + "Effect": "Allow", |
| 151 | + "Principal": { |
| 152 | + "AWS": "<ARN_SYSDIG_S3_ACCESS_ROLE>" |
| 153 | + }, |
| 154 | + "Action": "s3:GetObject", |
| 155 | + "Resource": "<ARN_CLOUDTRAIL_S3>/*" |
| 156 | +} |
| 157 | +``` |
| 158 | +<br/><br/> |
| 159 | + |
| 160 | + |
| 161 | +### 6. **Sysdig Compute** Workload deployment |
| 162 | + |
| 163 | +Following Step2. We will setup `SysdigComputeRole`, to be able to perform required actions by Secure for Cloud |
| 164 | +compute; work with the SQS and access S3 resources (this last one via assumeRole). |
| 165 | + |
| 166 | +```text |
| 167 | +{ |
| 168 | + "Version": "2012-10-17", |
| 169 | + "Statement": [ |
| 170 | + { |
| 171 | + "Effect": "Allow", |
| 172 | + "Action": [ |
| 173 | + "SQS:ReceiveMessage", |
| 174 | + "SQS:DeleteMessage" |
| 175 | + ], |
| 176 | + "Resource": "<ARN_CLOUDTRAIL_SNS_SQS>" |
| 177 | + }, |
| 178 | + { |
| 179 | + "Effect": "Allow", |
| 180 | + "Action": [ |
| 181 | + "sts:AssumeRole" |
| 182 | + ], |
| 183 | + "Resource": "<ARN_SYSDIG_S3_ACCESS_ROLE>" |
| 184 | + } |
| 185 | + ] |
| 186 | +} |
| 187 | +``` |
| 188 | + |
| 189 | +Now we will deploy the compute component, depending on the compute service |
| 190 | + |
| 191 | +#### A) EKS |
| 192 | + |
| 193 | +If using Kubernetes, we will make use of the [Sysdig cloud-connector helm chart](https://charts.sysdig. |
| 194 | +com/charts/cloud-connector/) component. |
| 195 | + |
| 196 | +Provided the following `values.yaml` template |
| 197 | +```helm |
| 198 | +-- values.yaml suggestion |
| 199 | +sysdig: |
| 200 | + url: "https://secure.sysdig.com" |
| 201 | + secureAPIToken: "SYSDIG_API_TOKEN" |
| 202 | +telemetryDeploymentMethod: "helm_aws_k8s_org" # not required but would help us |
| 203 | +aws: |
| 204 | + region: <SQS-AWS-REGION> |
| 205 | +ingestors: |
| 206 | + - cloudtrail-sns-sqs: |
| 207 | + queueURL:"<URL_CLOUDTRAIL_SNS_SQS>" # step 3 |
| 208 | + assumeRole:"<ARN_ROLE_SYSDIG_S3_ACCESS>" # step 4 |
| 209 | +``` |
| 210 | + |
| 211 | +We will install it |
| 212 | +```shell |
| 213 | +$ helm upgrade --install --create-namespace -n sysdig-cloud-connector sysdig-cloud-connector sysdig/cloud-connector -f values.yaml |
| 214 | +``` |
| 215 | + |
| 216 | +Test it |
| 217 | +```shell |
| 218 | +$ kubectl logs -f -n sysdig-cloud-connector deployment/sysdig-cloud-connector |
| 219 | +``` |
| 220 | + |
| 221 | +And if desired uninstall it |
| 222 | +```shell |
| 223 | +$ helm uninstall -n sysdig-cloud-connector sysdig-cloud-connector |
| 224 | +``` |
| 225 | + |
| 226 | +#### B) ECS |
| 227 | + |
| 228 | +If using , AWS ECS (Elastic Container Service), we will create a new Fargate Task. |
| 229 | + |
| 230 | +- TaskRole: Use previously created `SysdigComputeRole` |
| 231 | +- Task memory (GB): 0.5 and Task CPU (vCPU: 0.25 will suffice |
| 232 | +- Container definition: |
| 233 | + - Image: `quay.io/sysdig/cloud-connector:latest` |
| 234 | + - Port Mappings; bind port 5000:5000 tcp protocol |
| 235 | + - Environment variables |
| 236 | + - SECURE_URL |
| 237 | + - SECURE_API_TOKEN |
| 238 | + - CONFIG: A base64 encoded configuration of the cloud-connector service |
| 239 | + ``` |
| 240 | + logging: info |
| 241 | + rules: [] |
| 242 | + ingestors: |
| 243 | + - cloudtrail-sns-sqs: |
| 244 | + queueURL: <URL_CLOUDTRAIL_SNS_SQS> |
| 245 | + assumeRole: <ARN_ROLE_SYSDIG_S3_ACCESS> |
| 246 | + ``` |
| 247 | +<!-- |
| 248 | +
|
| 249 | +AWS Systems Manager |
| 250 | +Application Manager |
| 251 | +CustomGroup: iru |
| 252 | +
|
| 253 | +
|
| 254 | +AWS::SSM::Parameter |
| 255 | +Type: SecureString |
| 256 | +Data type: text |
| 257 | +
|
| 258 | +In ContainerDefinition, secrets |
| 259 | +- SECURE_API_TOKEN, `secretName` |
| 260 | +
|
| 261 | +
|
| 262 | +ExecutionRole |
| 263 | +{ |
| 264 | +"Version": "2012-10-17", |
| 265 | +"Statement": [ |
| 266 | +{ |
| 267 | +"Sid": "", |
| 268 | +"Effect": "Allow", |
| 269 | +"Action": "ssm:GetParameters", |
| 270 | +"Resource": "arn:aws:ssm:eu-west-3:**:parameter/**" |
| 271 | +} |
| 272 | +] |
| 273 | +} |
| 274 | +--> |
| 275 | +
|
| 276 | +
|
| 277 | +## Testing |
| 278 | +
|
| 279 | +Check within Sysdig Secure |
| 280 | +- Integrations > Cloud Accounts |
| 281 | +- Posture > Compliance for the compliance task schedule |
| 282 | +- Insights > Cloud Activity |
0 commit comments