docs: homogeneize three-way use-cases (#145)

Author: iru

use-cases/README.md

@@ -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.

use-cases/org-three-cross-account-s3-event-forward.md renamed to use-cases/org-three-way-ecs.md

@@ -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

use-cases/org-s3-k8s-filtered-account.md renamed to use-cases/org-three-way-k8s.md

@@ -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
 
@@ -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
@@ -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>"
 }
 ```