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.

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