Skip to content

docs: homogeneize three-way use-cases #145

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Nov 15, 2022
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion use-cases/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -46,7 +46,7 @@ If not Terraform nor Cloudformation suits, take a look at the `manual-*` prefixe
| Deployment Type | all Sysdig resources will be deployed within the selected account | Most Sysdig resources will be deployed within the selected account (just one), but some features, require resources to be deployed on all of the member-accounts (for Compliance and Image Scanning) . <br />One role is needed on the management account for cloudtrail-s3 event access |
| Target | will only analyse current account | handles all accounts (managed and member)|
| Drawbacks | cannot re-use another account Cloudtrail data (unless its deployed on the same account where the sns/s3 bucket is) | for scanning, a per-member-account access role is required |
| Optional resources usage limitations | - | For organizational example, Cloudtrail optional resources must exist in the management account. For other setups check other alternative use-cases</br><ul><li>[manual deployment; cloudtrail-s3 bucket in another member account](./manual-org-three-way.md)</li><li>[terraform-based deployment; cloudtrail with cloudtrail-s3 bucket in another member account. k8s flavor](./org-s3-k8s-filtered-account.md)</li><li>[terraform-based deployment; cloudtrail with cloudtrail-s3 bucket in another member account. ecs flavor](./org-three-cross-account-s3-event-forward.md)</li></ul>|
| Optional resources usage limitations | - | For organizational example, Cloudtrail optional resources must exist in the management account. For other setups check other alternative use-cases</br><ul><li>[manual deployment; cloudtrail-s3 bucket in another member account](./manual-org-three-way.md)</li><li>[terraform-based deployment; cloudtrail with cloudtrail-s3 bucket in another member account. k8s flavor](./org-three-way-k8s.md)</li><li>[terraform-based deployment; cloudtrail with cloudtrail-s3 bucket in another member account. ecs flavor](./org-three-way-ecs.md)</li></ul>|
| More Info | [single-ecs](https://github.com/sysdiglabs/terraform-aws-secure-for-cloud/tree/master/examples/single-account-ecs), [single-apprunner](https://github.com/sysdiglabs/terraform-aws-secure-for-cloud/tree/master/examples/single-account-apprunner), [single-k8s](https://github.com/sysdiglabs/terraform-aws-secure-for-cloud/tree/master/examples/single-account-k8s) | [organizational](https://github.com/sysdiglabs/terraform-aws-secure-for-cloud/tree/master/examples/organizational) |

With both examples `single` and `org`, you can customize the desired features to de deployed with the `deploy_*` input vars to avoid deploying more than wanted.
Original file line number Diff line number Diff line change
@@ -1,10 +1,13 @@
# OrganizationSetup - Three way Cross-Account - Cloudtrail with no SNS - Event Notification with S3-SNS-SQS
# OrganizationSetup - Three way Cross-Account - ECS

## Use-Case explanation

This use case will cover
This use case will cover a three-way cross-account setup (typical from AWS ControlTower landing page).
With ECS as workload-type.
<br/>This is terraform-based guidelines, but can also check [Manual Organizational Setup - Three-Way Cross-Account ](./manual-org-three-way.md)

- **User Infrastructure Setup**: AWS Organization Setup with three-way account setup

- **User Infrastructure Setup**:
1. Management Account
- Organizational Cloudtrail with no SNS activation
2. Log Archive Account
Expand Down
Original file line number Diff line number Diff line change
@@ -1,36 +1,27 @@
# OrganizationalSetup - Existing CloudtrailEventsOnS3 - Existing K8s Cluster - Filtered Account
# OrganizationalSetup - Three way Cross-Account - K8S

## Use-Case explanation

**Current User Setup**

- [X] organizational setup
- [ ] organizational cloudtrail that reports to SNS and persists events in a managed-account stored S3 bucket
- [X] centralized S3 bucket with cloudtrail-events
- [ ] member account usage - all required and pre-existing resources exist in the same account
- [X] member account usage - all required resources are in scattered
- [X] pre-existing resources
- [ ] k8s cluster we want to use to deploy Sysdig for Cloud workload
- [ ] organizational cloudtrail, reporting to an SNS topic and delivering events to the S3 bucket
- [ ] ecs cluster/vpc/subnet we want to use to deploy Sysdig for Cloud workload


**Sysdig Secure For Cloud Features**

- [X] threat-detection
- [X] account-specific
- [ ] all accounts of the organization (management account included)
- [ ] image-scanning (WIP?)
- [ ] compliance (WIP?)
- [ ] CIEM (WIP?)

**Other Requirements**

- [X] pre-existing kubernetes management vía service account (WIP)
<br/>this has not been tested yet, we rely on an `accessKey` created specifically for Sysdig-For-Cloud.
<!--
Skip step 4 and remove `aws_access_key_id` and `aws_secret_access_key` parameters from `org_k8s_threat_reuse_cloudtrail` module
-->
This use case will cover a three-way cross-account setup (typical from AWS ControlTower landing page).
With EKS as workload-type.
<br/>This is terraform-based guidelines, but can also check [Manual Organizational Setup - Three-Way Cross-Account ](./manual-org-three-way.md)

- **User Infrastructure Setup**:
1. Management Account
- Organizational Cloudtrail with no SNS activation
2. Log Archive Account
- Cloudtrail-S3 bucket, with event notification to an SNS > SQS
3. Member Account
- Sysdig Secure for cloud deployment
- Existing K8S Cluster
- permission setup rely on an `accessKey/secretAccessKey` parameters of the workload, but can setup the
service-account manually and ignore those two parameters.

- Required **Sysdig Secure For Cloud [Features](https://docs.sysdig.com/en/docs/installation/sysdig-secure-for-cloud/)**
- Threat-Detection
- :warning: Posture; Compliance + Identity Access Management not delivered with this use-case. Can use [manual compliance setup](./manual-compliance.md)
- :warning: Cloud image scanning is not supported yet


## Suggested building-blocks

Expand Down Expand Up @@ -77,7 +68,8 @@ provider "helm" {
```text
cloudtrail_s3_name=cloudtrail-logging-237944556329
```
2. Populate `CLOUDTRAIL_S3_FILTER_PREFIX` in order to ingest a specific-account. Otherwise, just remove its assignation
2. Optionally, populate `CLOUDTRAIL_S3_FILTER_PREFIX` in order to ingest a specific-account. Otherwise, just remove
its assignation
<br/>ex.:
```text
s3_event_notification_filter_prefix=cloudtrail/AWSLogs/237944556329
Expand All @@ -90,7 +82,7 @@ module "cloudtrail_s3_sns_sqs" {
}
source = "sysdiglabs/secure-for-cloud/aws//modules/infrastructure/cloudtrail_s3-sns-sqs"
cloudtrail_s3_name = "<CLOUDTRAIL_S3_NAME>"
s3_event_notification_filter_prefix="<CLOUDTRAIL_S3_FILTER_PREFIX>"
# s3_event_notification_filter_prefix="<CLOUDTRAIL_S3_FILTER_PREFIX>"
}
```

Expand Down