Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Security & Policy Configurations for Infrastructure as Code

Security & Policy Configurations for Infrastructure as Code

Presented at Cloud Native @Scale Meetup on June 30, 2021.

When you use cloud infrastructure, you might find yourself accidentally applying a configuration for an open storage bucket, unencrypted queue, or unrestricted access control. At worst, these misconfigurations can be exploited by bad actors. At best, they get duplicated across an organization without anyone knowing better. Over time, this duplication becomes painful to manage as more teams collaborate on infrastructure, systems grow more complex, and new audit requirements come to light. How do you know your application and infrastructure configurations adhere to compliance and security standards? In this talk, you'll learn how to scale your policy as code for cloud infrastructure. We'll get hands-on with a combination of static and dynamic analysis to implement rules that automatically verify the security and compliance of your configurations as part of your development lifecycle.

Be8b596c46f4c9a1aec6a7586af33134?s=128

Rosemary Wang

June 30, 2021
Tweet

More Decks by Rosemary Wang

Other Decks in Technology

Transcript

  1. Security & Policy Con fi gurations for Infrastructure as Code

    Cloud Native @Scale June 2021
  2. infrastructure as code (This example creates policies in a secrets

    manager.) resource "vault_policy" “payments_pipeline" { name = var.pipeline_name policy = <<EOT path "kv/*" { capabilities = ["read"] } path "auth/token/create" { capabilities = ["update"] } path “database/*" { capabilities = ["create", "read", "update", "delete"] } EOT }
  3. “It works. I’ll just copy it.”

  4. copied infrastructure as code (This is…. fi ne?) resource "vault_policy"

    “payments_pipeline" { name = var.pipeline_name policy = <<EOT path "kv/*" { capabilities = ["read"] } path "auth/token/create" { capabilities = ["update"] } path “database/*" { capabilities = ["create", "read", "update", "delete"] } EOT }
  5. copied infrastructure as code (This is…. fi ne?) resource "vault_policy"

    “payments_pipeline" { name = var.pipeline_name policy = <<EOT path "kv/*" { capabilities = ["read"] } path "auth/token/create" { capabilities = ["update"] } path “database/*" { capabilities = ["create", "read", "update", "delete"] } EOT } resource "vault_policy" “payments_pipeline" { name = var.pipeline_name policy = <<EOT path "kv/*" { capabilities = ["read"] } path "auth/token/create" { capabilities = ["update"] } path “database/*" { capabilities = ["create", "read", "update", "delete"] } EOT } resource "vault_policy" “payments_pipeline" { name = var.pipeline_name policy = <<EOT path "kv/*" { capabilities = ["read"] } path "auth/token/create" { capabilities = ["update"] } path “database/*" { capabilities = ["create", "read", "update", "delete"] } EOT } resource "vault_policy" “payments_pipeline" { name = var.pipeline_name policy = <<EOT path "kv/*" { capabilities = ["read"] } path "auth/token/create" { capabilities = ["update"] } path “database/*" { capabilities = ["create", "read", "update", "delete"] } EOT } resource "vault_policy" “payments_pipeline" { name = var.pipeline_name policy = <<EOT path "kv/*" { capabilities = ["read"] } path "auth/token/create" { capabilities = ["update"] } path “database/*" { capabilities = ["create", "read", "update", "delete"] } EOT } resource "vault_policy" “payments_pipeline" { name = var.pipeline_name policy = <<EOT path "kv/*" { capabilities = ["read"] } path "auth/token/create" { capabilities = ["update"] } path “database/*" { capabilities = ["create", "read", "update", "delete"] } EOT }
  6. Rosemary Wang Developer Advocate at HashiCorp @joatmon08 joatmon08.github.io (Not my

    cat.)
  7. Deliver infrastructure and secure it across many teams.

  8. 5 Things I Learned 1. Static analysis 2. Dynamic analysis

    3. Modularize 4. Pipelines as code 5. Enforcement levels
  9. 1. Static analysis

  10. Does the change adhere to our policy and security 


    standards? Release it to infrastructure. Yes No Update infrastructure as code.
  11. Lots of terms • Shift-left security testing • Fitness functions

    (evolutionary architecture) • Testing infrastructure as code
  12. Security Testing Tool Parse for fi elds JSON or metadata

    format Con fi guration or planned state Check fi eld values Assert pass or fail
  13. Use Cases •Network policy •Infrastructure con fi guration •Access control

    & logging
  14. resource "vault_policy" “payments_pipeline" { name = var.pipeline_name policy = <<EOT

    path "kv/*" { capabilities = ["read"] } path "auth/token/create" { capabilities = ["update"] } path “database/*" { capabilities = ["create", "read", "update", "delete"] } EOT } Policy: Pipelines should not be able to update Vault tokens.
  15. 2. Dynamic analysis

  16. Lots of terms • Vulnerability management • Security scanning •

    Remediation
  17. Security Testing Tool Parse for fi elds JSON or metadata

    format Active state or infrastructure API Check fi eld values Assert pass or fail Run on a regular schedule.
  18. resource "vault_policy" “payments_pipeline" { name = var.pipeline_name policy = <<EOT

    path "kv/*" { capabilities = ["read"] } path "auth/token/create" { capabilities = ["update"] } path “database/*" { capabilities = ["create", "read", "update", "delete"] } EOT } Policy: Only pipelines with self-hosted runners on private networks should have access to con fi gure or remove database secrets.
  19. import "sockaddr" import "strings" # Check for create, update, or

    delete actions to database secrets precond = rule { request.operation in ["create", "update", "delete"] and strings.has_prefix(request.path, “database/") } # Requests to come only from self-hosted pipeline runner in a private network cidrcheck = rule { sockaddr.is_contained(request.connection.remote_addr, "172.16.0.9/32") } # Check the precondition before execute the cidrcheck main = rule when precond { cidrcheck }
  20. Other Tools •Vulnerability Scanning (Snyk, Tenable) •Cloud Infrastructure Scanning (Forseti,

    Cloudcheckr) •Authorization (Sentinel, OPA)
  21. 3. Modularize

  22. Repositories to share… •Organizational policies •Organizational benchmarks •Industry benchmarks

  23. Dividing Modules • Function • Infrastructure provider • Business domain

  24. Repository: shared-org-policies naming tagging aws azure gcp billing secrets access-management

    vulnerability-management runtime-security Repository: infrastructure-policies aws (reference) shared-org-policies/tagging/aws azure gcp datadog Repository: payments-infrastructure-policies pci (reference) infrastructure-policies/aws (reference) shared-org-policies/vulnerability-management Build Test Deploy Security Test Release
  25. 4. Pipelines as code

  26. Repository: shared-org-policies naming tagging aws azure gcp billing secrets access-management

    vulnerability-management runtime-security Repository: infrastructure-policies aws (reference) shared-org-policies/tagging/aws azure gcp datadog Repository: payments-infrastructure-policies pci (reference) infrastructure-policies/aws (reference) shared-org-policies/vulnerability-management Build Test Deploy Security Test Release
  27. De fi ne Pipelines “as Code” •Use templates •Require “security

    testing” stages •Run asynchronously
  28. Build Test Deploy Security Test Release Test

  29. 5. Enforcement levels

  30. Choose one: •Hard mandatory •Soft mandatory •Advisory

  31. 5 Things I Learned 1. Static analysis 2. Dynamic analysis

    3. Modularize 4. Pipelines as code 5. Enforcement levels
  32. Demos & Tools • Pytest + Terraform • Inspec +

    Docker • Open Policy Agent + JSON API Response
  33. References • ncp.nist.gov// • github.com/joatmon08/policy-as-code • github.com/tracypholmes/policy-as-code-workshop • github.com/joatmon08/tdd-infrastructure#policy-as-code- with-security-scanning

    Find these slides at joatmon08.github.io