While CSPs often provide tools to help manage cloud configuration, misconfiguration of cloud resources remains the most prevalent cloud vulnerability “ “ Configuration is a security risk
Insecure by default Limits to prevent denial of service CPU and Memory Limits spec: containers: - name: db image: mysql resources: limits: memory: "128Mi" cpu: "500m" Limiting the expected CPU and Memory limits has operational as well as security benefits. In the context of security this is about limiting the impact of potential denial of service attacks to affecting the app rather than the node and potentially the whole cluster.
Insecure by default Root level permissions by default runAsNonRoot apiVersion: v1 kind: Pod metadata: name: hello-world spec: containers: ... securityContext: readOnlyRootFilesystem: true runAsNonRoot: true By default, containers can run as the root user. This property prevents that at the container runtime level, meaning an attacker would only have limited permissions if they we’re to be able to execute a command in the context of the container.
Insecure by default Writable file systems making attackers lives easier readOnlyRootFilesystem apiVersion: v1 kind: Pod metadata: name: hello-world spec: containers: ... securityContext: readOnlyRootFilesystem: true runAsNonRoot: true By default the file system mounted for the container will be writable. That means an attacker who compromises the container can also write to disk, which makes certain attacks easier. If you’re containers are stateless then you don’t need a writable filesystem.
Insecure by default Access to all the power of linux by default Capabilities apiVersion: v1 kind: Pod metadata: name: hello-world spec: containers: ... securityContext: capabilities: add: ["NET_ADMIN", "SYS_TIME"] drop: ["ALL"] Linux capabilities control at a low-level what processes in the container can do. From being able to write to disk to being able to communicate over the network. Dropping all capabilities and adding in those that are required is possible but requires understanding the list of capabilities.
KubeSec github.com/controlplaneio/kubesec Security risk analysis for Kubernetes resources Active, started 2 years ago 245 Static set of rules @sublimino, @stefanprodan
Conftest github.com/instrumenta/conftest Write tests against structured configuration data using the Open Policy Agent Rego query language. - Currently supports YAML, JSON, INI, TOML, HOCON, HCL, CUE, Dockerfile, HCL2, EDN, VCL and XML - Share policies using OCI registries, Git, S3 - Built-in debugging and testing tools Active, started 10 months ago 902 Write your own rules @garethr, @jpreese, @blokje5, @boranx, @KeisukeYamashita, @xchapter7x, @proplex, ...
What is Open Policy Agent? github.com/open-policy-agent/opa Service OPA .rego Query (any JSON value) Decision (any JSON value) Data (JSON) Policy (Rego) Request, Event, etc. - An open source policy engine - Written in Go - WebAssembly support coming along - A CNCF project - Usable as a library and a service - A vibrant open source community - Provides a declarative DSL for writing policy called Rego
Conftest Kubernetes assertions in Rego package main deny[msg] { input.kind = "Deployment" not input.spec.template.spec.securityContext.runAsNonRoot = true msg = "Containers must not run as root" } deny[msg] { input.kind = "Deployment" not input.spec.selector.matchLabels.app msg = "Containers must provide app label for pod selectors" }
Conftest Running tests against your configuration $ conftest test deployment.yaml FAIL - deployment.yaml - Containers must not run as root $ echo $status 1
Conftest Shareable policies mean lower barrier to entry $ conftest test --update github.com/instrumenta/policies.git//kubernetes deployment+service.yaml PASS - deployment+service.yaml - data.main.violation FAIL - deployment+service.yaml - hello-kubernetes in the Deployment hello-kubernetes does not hav FAIL - deployment+service.yaml - hello-kubernetes in the Deployment hello-kubernetes does not hav FAIL - deployment+service.yaml - hello-kubernetes in the Deployment hello-kubernetes doesn't drop FAIL - deployment+service.yaml - hello-kubernetes in the Deployment hello-kubernetes is not using FAIL - deployment+service.yaml - hello-kubernetes in the Deployment hello-kubernetes allows privi FAIL - deployment+service.yaml - hello-kubernetes in the Deployment hello-kubernetes is running a
Terrascan github.com/cesar-rodriguez/terrascan A collection of security and best practice tests for static code analysis of terraform templates using terraform_validate. Active, started 4 months ago 333 Python 35 rules, mainly for AWS @cesar-rodriguez Ran 16 tests in 0.015s OK Processed 19 files in C:\DEV\terraforms\backends\10-network-analytics Results (took 1.08 seconds): Failures: (2) [high] [aws_dynamodb_table.encryption.server_side_encryption.ena [high] [aws_s3_bucket.noEncryption] should have property: 'server Errors: (0)
Terrafirma github.com/wayfair/terrafirma Terrafirma is a Terraform static analysis tool designed for detecting security misconfigurations. Inactive, created 2 years ago 17 Python 14 rules, mainly for GCP --- ISSUE FW_1 - Source range open to Internet - SEVERITY WARN - RESOURCE example_fw_rule.google_compute_firewall --- ISSUE FW_2 - SSH Open - SEVERITY INFO - RESOURCE example_fw_rule.google_compute_firewall
Checkov github.com/bridgecrewio/checkov Checkov is a static code analysis tool for infrastructure as code. It scans cloud infrastructure managed in Terraform and detects misconfigurations. Active, created 3 months ago 511 Python 50 rules, for AWS, Azure and GCP @schosterbarak, @tronxd, @guyeisenkot, @nimrodkor Passed checks: 4, Failed checks: 0, Skipped checks: 0 Check: "Ensure all data stored in the S3 bucket is securely encrypted at rest" PASSED for resource: aws_s3_bucket.foo-bucket File: /example.tf:1-25 Check: "Ensure the S3 bucket has access logging enabled" PASSED for resource: aws_s3_bucket.foo-bucket File: /example.tf:1-25
tfsec github.com/liamg/tfsec tfsec uses static analysis of your terraform templates to spot potential security issues - Checks for sensitive data inclusion across all providers - Checks for violations of AWS, Azure and GCP security best practice recommendations - Scans modules (currently only local modules are supported) - Evaluates expressions as well as literal values Active, started 4 months ago 927 35 rules, mainly for AWS @liamg
Conftest (again) Terraform/HCL assertions in Rego package main deny[msg] { proto := input.resource.aws_alb_listener[lb].protocol proto == "HTTP" msg = sprintf("ALB `%v` is using HTTP rather than HTTPS", [lb]) } deny[msg] { rule := input.resource.aws_security_group_rule[name] rule.type == "ingress" contains(rule.cidr_blocks, "0.0.0.0/0") msg = sprintf("ASG `%v` defines a fully open ingress", [name]) }
Conftest (again) Running tests against your Terraform code $ conftest test -i hcl2 main.tf FAIL - main.tf - ALB `my-alb-listener` is using HTTP rather than HTTPS FAIL - main.tf - ASG `my-rule` defines a fully open ingress FAIL - main.tf - Azure disk `source` is not encrypted Decision (any JSON value)
Conftest Write unit tests for Rego in Rego test_blank_input { no_violations with input as {} } test_correctly_encrypted_azure_disk { no_violations with input as {"resource": { "azurerm_managed_disk": { "sample": { "encrypted } test_unencrypted_azure_disk { deny["Azure disk `sample` is not encrypted"] with input as {"resource": { "azurerm_managed_ }
Infrastructure is increasingly part of the app Your configuration is in the same repo as your code, maintained by the same developers and going through CI
Shift security left Automatically catching security issues during development means less issues in production, and more time to focus on finding and fixing them
garethr
bumptakayuki
eiki
junjikoide
sansantech
kurochan
iwamot
nagix
wernerkrauss
nktamago
yusuke
dsa28s
yanzm
akosma
dougneiner
smashingmag
marktimemedia
aki_iinuma
eileencodes
erikaheidi
chrislema
moore
tammielis
caitiem20
3n