Current User Setup
- multi-account setup
- per-account cloudtrail, each reporting to their own S3 bucket
- pre-existing resources
- [?] multiple cloudtrail-S3 buckets synced to a single S3 bucket to which an SQS is attached
- [?] multiple cloudtrail-S3 buckets reporting to same SQS
- k8s cluster we want to use to deploy Sysdig for Cloud workload
- permission setup
- [?] sysdig workload account usage - all required and pre-existing resources exist in the same account
- [?] sysdig workload account usage - all required resources are in scattered accounts
Sysdig Secure For Cloud Features
From the Secure for cloud AWS available features
- threat-detection
- account-specific
- [?] all individual-cloudtrail accounts need to be analysed
- image-scanning (ECR and ECS)
- compliance/benchmark
- CIEM
Other Requirements
- [?] pre-existing kubernetes management vía service account (WIP)
this has not been tested yet, we rely on anaccessKeyId/secretAccessKey
- be able to parametrize
nodeSelector
andtolerations
on the k8s deployment configuration
For clients that only require thread-detection feature, and do not have an organizational cloudtrail setup, but multiple-accounts,
we can make use of the cloud-connector aws-cloudtrail-s3-sns-sqs
ingestor
This processes through a single SQS AWS queue the events that come through a single S3 bucket (through an SNS topic) or multiple S3 buckets (that through several SNS topics, report to a single SQS topic).
-
Define different AWS providers
WIP.
- ?? We need to know the account where Sysdig Secure for cloud workload will be deployed
- And the accounts where the cloudtrail-S3 bucket(s) will be
- Helm provider definition
Sysdig workload will be deployed through its official Helm cloud-connector chart.
Note: Configure Helm Provider for Kubernetes cluster
ex:.
provider "helm" {
kubernetes {
config_path = "~/.kube/config"
}
}
- Cloudtrail-S3-SNS-SQS
WIP.
Create an SQS que that will subscribe to one S3-SNS (1) or several S3 buckets SNS topics (2)
We currently provide a module to create first use-case, one S3-SNS-SQS (1), but can work on providing a way to automatize the later (2)
- Kubernetes Multi-Account AWS Permissions to be able to handle S3/SQS operations Helm Cloud-Connector chart requires specific AWS credentials to be passed by parameter, a new user + access key will be created within account, to be able to fetch the events in the S3 bucket (1) or several S3 buckets (2)
WIP.
We currently provide a module to create first use-case,
modules/infrastructure/permissions/iam-user
(1),
but can work on providing a way to automatize the later (2)
-
Sysdig workload deployment on K8s
- Populate
sysdig_secure_url
,SYSDID_SECURE_API_TOKEN
andREGION
- WIP. enable terraform module to be able to define
nodeSelector
andtolerations
parameters of the cloud-connector helm chart
- Populate
resource "helm_release" "cloud_connector" {
provider = helm
name = "cloud-connector"
repository = "https://charts.sysdig.com"
chart = "cloud-connector"
create_namespace = true
namespace = "sysdig"
set {
name = "image.pullPolicy"
value = "Always"
}
set {
name = "sysdig.url"
value = "<sysdig_secure_url>"
}
set_sensitive {
name = "sysdig.secureAPIToken"
value = "<SYSDIG_SECURE_API_TOKEN>"
}
set_sensitive {
name = "aws.accessKeyId"
value = "<AWS_ACCESS_KEY>"
}
set_sensitive {
name = "aws.secretAccessKey"
value = "<AWS_SECRET_ACCESS_KEY>"
}
set {
name = "aws.region"
value = "<REGION>"
}
set {
name = "nodeSelector.<NODE_SELECTOR_LABEL>"
value = "<NODE_SELECTOR_LABEL_VALUE>"
}
set {
name = "tolerations[0].key"
value = "<TOLERATION_KEY>"
}
set {
name = "tolerations[0].operator"
value = "<TOLERATION_OPERATOR>"
}
set {
name = "tolerations[0].value"
value = "<TOLERATION_VALUE>"
}
set {
name = "tolerations[0].effect"
value = "<TOLERATION_EFFECT>"
}
values = [
<<CONFIG
logging: info
ingestors:
- aws-cloudtrail-s3-sns-sqs:
queueURL: CLOUDTRAIL_S3_SNS_SQS_URL
CONFIG
]
}