The perils of configuration security

The perils of configuration security

Talk from MyDevSecOps on configuration security, with a discussion of the problem and lots of examples from the Kubernetes and Terraform ecosystem.

98234c645fe8c935edc0fec0186d28b8?s=128

Gareth Rushgrove

March 05, 2020
Tweet

Transcript

  1. The perils of configuration security Gareth Rushgrove

  2. Gareth Rushgrove Director, Product Management, Snyk Devops Weekly curator Open

    Source contributor @garethr
  3. Agenda Configuration security 01 Static analysis 02 Kubernetes 03 Terraform

    04 Conclusions 05
  4. Configuration security In a world of infrastructure as code

  5. Configuration is increasingly in code

  6. Configuration is increasingly in code YAML

  7. Configuration is everywhere Azure ARM 250k+ Terraform 140k+ Kubernetes 2m+

    AWS CF 90k+ Serverless 40k+ Compose 600k+
  8. The financial giant said the intruder exploited a configuration vulnerability

    “ “ Configuration is a security risk
  9. Some kind of misconfiguration is encountered on an penetration test

    over 96% of the time. “ “ Configuration is a security risk
  10. 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
  11. Static analysis A very quick introduction

  12. Static analysis Static program analysis is the analysis of computer

    software that is performed without actually executing programs
  13. A typical testing progression Acceptance tests Unit tests Integration tests

    Static analysis
  14. The importance of fast feedback Acceptance tests Unit tests Integration

    tests Static analysis Fast Middling Slow Slower
  15. Declarative Config Static analysis

  16. Kubernetes An example ecosystem

  17. The current configuration explosion Kubernetes YAML files apiVersion: apps/v1 kind:

    Deployment metadata: name: hello-kubernetes spec: replicas: 3 selector: matchLabels: app: hello-kubernetes template: metadata: labels: app: hello-kubernetes spec: containers: - name: hello-kubernetes ~2 million Kubernetes configuration files public on GitHub
  18. 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.
  19. 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.
  20. 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.
  21. 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.
  22. KubeSec github.com/controlplaneio/kubesec Security risk analysis for Kubernetes resources Active, started

    2 years ago 245 Static set of rules @sublimino, @stefanprodan
  23. 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, ...
  24. 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
  25. Conftest integrations Easy to run in common CI/CD systems

  26. 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" }
  27. Conftest Running tests against your configuration $ conftest test deployment.yaml

    FAIL - deployment.yaml - Containers must not run as root $ echo $status 1
  28. 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
  29. Demo

  30. Terraform Another example ecosystem

  31. Insecure Terraform Can you spot issues in the following code?

    resource "aws_security_group_rule" "my-rule" { type = "ingress" cidr_blocks = ["0.0.0.0/0"] } resource "aws_alb_listener" "my-alb-listener" { port = "80" protocol = "HTTP" } resource "aws_db_security_group" "my-group" { } resource "azurerm_managed_disk" "source" { encryption_settings { enabled = false } }
  32. Insecure Terraform Can you spot issues in the following code?

    resource "aws_security_group_rule" "my-rule" { type = "ingress" cidr_blocks = ["0.0.0.0/0"] } resource "aws_alb_listener" "my-alb-listener" { port = "80" protocol = "HTTP" } resource "aws_db_security_group" "my-group" { } resource "azurerm_managed_disk" "source" { encryption_settings { enabled = false } } Wide open ingress rule
  33. Insecure Terraform Can you spot issues in the following code?

    resource "aws_security_group_rule" "my-rule" { type = "ingress" cidr_blocks = ["0.0.0.0/0"] } resource "aws_alb_listener" "my-alb-listener" { port = "80" protocol = "HTTP" } resource "aws_db_security_group" "my-group" { } resource "azurerm_managed_disk" "source" { encryption_settings { enabled = false } } Use of unencrypted transport protocol
  34. Insecure Terraform Can you spot issues in the following code?

    resource "aws_security_group_rule" "my-rule" { type = "ingress" cidr_blocks = ["0.0.0.0/0"] } resource "aws_alb_listener" "my-alb-listener" { port = "80" protocol = "HTTP" } resource "aws_db_security_group" "my-group" { } resource "azurerm_managed_disk" "source" { encryption_settings { enabled = false } } Unencrypted storage
  35. Center for Internet Security Benchmarks

  36. CIS Benchmarks Azure and AWS

  37. 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)
  38. 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
  39. 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
  40. 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
  41. tfsec Detect common configuration issues $ tfsec 5 potential problems

    detected: Problem 1 [AWS018][ERROR] Resource 'aws_security_group_rule.my-rule' should include a description for auditing purposes. /Users/garethr/Documents/terraform-security/main.tf:1-4 1 | resource "aws_security_group_rule" "my-rule" { 2 | type = "ingress" 3 | cidr_blocks = ["0.0.0.0/0"] 4 | } 5 | 6 | resource "aws_alb_listener" "my-alb-listener"{ 7 | port = "80" See https://github.com/liamg/tfsec/wiki/AWS018 for more information. Problem 2 [AWS006][WARNING] Resource 'aws_security_group_rule.my-rule' defines a fully open ingress security group rule. /Users/garethr/Documents/terraform-security/main.tf:3 Decision (any JSON value)
  42. 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]) }
  43. 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)
  44. 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_ }
  45. Demo

  46. Conclusions If all you remember is...

  47. 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
  48. Infrastructure as code leads to its own security challenges But

    static analysis is surprisingly useful when applied to declarative languages
  49. Shift security left Automatically catching security issues during development means

    less issues in production, and more time to focus on finding and fixing them
  50. Thanks for listening Sign up for free at snyk.io/signup