Slide 1

Slide 1 text

 Policy as Code: Intro to Sentinel @armon

Slide 2

Slide 2 text

 Armon Dadgar @armon

Slide 3

Slide 3 text

@armon

Slide 4

Slide 4 text

“POLICY AS CODE”

Slide 5

Slide 5 text

“INFRASTRUCTURE AS CODE”

Slide 6

Slide 6 text

• Before: Artisanal and Handcrafted • Point-and-Click UX • SSH + Manual Setup • Rsync between machines • etc INFRASTRUCTURE BEFORE

Slide 7

Slide 7 text

• After: Automated and Standardized • Single source of truth • Automated provisioning • Enables Scale INFRASTRUCTURE AS CODE

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

• Learn from Software Development • Versioning (Rollbacks) • Peer Review • Abstraction / Encapsulation • Code Reuse • Automation and Leverage BENEFITS

Slide 10

Slide 10 text

PROVISIONING A DATACENTER

Slide 11

Slide 11 text

Developers IT Operations Networking Security Procurement Sysadmins Finance Legal

Slide 12

Slide 12 text

• Replace ticketing workflows with APIs • Public Cloud consolidated many concerns • Private Cloud brings similar APIs • Enables Infrastructure as Code • Huge increase in leverage UBIQUITOUS APIS

Slide 13

Slide 13 text

PARADOX OF AUTOMATION

Slide 14

Slide 14 text

SANITY CHECKING IT Ops Procurement “Please provision 5000 VMs”

Slide 15

Slide 15 text

SANITY CHECKING IT Ops Procurement “Are you sure 5000?”

Slide 16

Slide 16 text

SANITY CHECKING IT Ops Cloud “Please provision 5000 VMs”

Slide 17

Slide 17 text

SANITY CHECKING IT Ops Cloud “Done!”

Slide 18

Slide 18 text

• Paradox of Automation • Accidental Error • Compliance Bypass • Malicious Intent SCALING AUTOMATION

Slide 19

Slide 19 text

• Governs Infrastructure as Code • Defines a sandbox to automate in • Codify business regulation and “sanity checking” POLICY AS CODE

Slide 20

Slide 20 text

• Separate teams for Procurement / IT Operations / etc • Bulkhead against failures • Separate authors • Policy as Code (Compliance / Security) • Infrastructure as Code (Operators / Developers) SEPARATION OF RESPONSIBILITY

Slide 21

Slide 21 text

POLICY AS CODE

Slide 22

Slide 22 text

• Changes only during business hours • Min / Max number of service instances • Instance types allowed • Public Cloud regions • Ensure resources are tagged (billing, tenancy) • Certified containers / AMIs only EXAMPLE POLICIES

Slide 23

Slide 23 text

• Security / Compliance teams define and enforce • Not familiar with “As Code” approach • Need to test policies ORGANIZATIONAL CHALLENGES

Slide 24

Slide 24 text

SENTINEL

Slide 25

Slide 25 text

• “Policy as Code Framework” • Sentinel Language Specification* • Golang Embedded Runtime • Simulator tool • Import SDK WHAT IS SENTINEL * https://docs.hashicorp.com/sentinel/language/spec

Slide 26

Slide 26 text

• Non-programmer friendly • Easy to Embed • Simple • Debuggable • Go Friendly DESIGN GOALS

Slide 27

Slide 27 text

• Language must be read and written by those with little to no programming experience • Traditional constructs should be available, but not needed for most policies NON-PROGRAMMER FRIENDLY

Slide 28

Slide 28 text

• Impacts Runtime more than Language • No support for unsafe operations (arbitrary memory access) • Must be easy to sandbox • Active Enforcement • Prevent Violation A Priori • Passive Enforcement • Detect Violation Post Hoc EASY TO EMBED

Slide 29

Slide 29 text

• Simple types (string, int, bool) at the expense of performance or exactness • Policies are typically small and don’t need to much flexibility • Ideally only one way to do something • “Zen of Python” SIMPLE

Slide 30

Slide 30 text

• Easy to debug and test for those not familiar • Often the sharpest corner when learning DEBUGABBLE

Slide 31

Slide 31 text

• Majority of HashiCorp tooling is Go • Simple to integration • Minimal changes to tooling / process • Performance implications GO FRIENDLY

Slide 32

Slide 32 text

NOT INVENTED HERE?

Slide 33

Slide 33 text

• JavaScript, Python, Lua, Ruby • Non-programmer friendliness • Embeddable • Go friendliness EXISTING LANGUAGES

Slide 34

Slide 34 text

• Sentinel has dynamic types • Wanted static typing • Much friendlier to non-programmers • External integrations more complex DESIGN DECISIONS: DYNAMIC TYPING

Slide 35

Slide 35 text

import "time" deployment_window = rule { time.hour > 8 and time.hour < 17 } main = rule { deployment_window } First Class Rules

Slide 36

Slide 36 text

• Equivalent to functions • Lazy • Memoized • Performance for redundant rules • More Friendly DESIGN DECISIONS: FIRST CLASS RULES

Slide 37

Slide 37 text

import "external" external_ready = rule { external.expensive_call() } internal_override = rule { … } main = rule { external_ready or (!external_ready and interal_override) }

Slide 38

Slide 38 text

• Dedicated Existential Operators • any: expression is true for any term • all: expression is true for all terms • “All artifacts must come from a trusted source” • “Any of the tags must be the tenant ID” DESIGN DECISIONS: EXISTENTIAL OPERATORS

Slide 39

Slide 39 text

• Plain English Operators • and, or, contains, in, is, matches, not • Traditional Operators • Easier for non-programmers DESIGN DECISIONS: SIMPLE OPERATORS

Slide 40

Slide 40 text

• Avoid Exceptions / Panic • Must propagate errors • “Infectious” Undefined • Can be escaped by boolean logic with else DESIGN DECISIONS: UNDEFINED VALUE

Slide 41

Slide 41 text

import “time” # valid_bar will be undefined obj = null valid_bar = rule { obj.foo.bar == 42 } valid_time = rule { time.hour > 8 } main = rule { (valid_bar or valid_time) else false }

Slide 42

Slide 42 text

BASIC SYNTAX

Slide 43

Slide 43 text

main = rule { all obj.items as item { item matches "my-item-[a-z0-9]+" } }

Slide 44

Slide 44 text

sum = func(list) { count = 0 for list as elem { count += elem } return count } main = rule { sum(obj.items) is 42 }

Slide 45

Slide 45 text

allowed_size = ["m3.small", "m4.small", "c1.large"] allowed_regions = {“stage”:“east","prod":“west"} valid_provider = rule { all providers as p { p.region is allowed_regions[env.region] }
 } valid_resource = rule { all resources as r { r.type is "instance" and r.size in allowed_size } } main = rule { valid_provider and valid_resource}

Slide 46

Slide 46 text

RUNTIME IMPLEMENTATION

Slide 47

Slide 47 text

• Lexer / Parser • Semantic Checker • Evaluator / Interpreter • Standard Library KEEP IT SIMPLE

Slide 48

Slide 48 text

• Learn From Go • Maintain the position offsets (line, column) • Support a “fmt” command • Canonical Format LEXER / PARSER

Slide 49

Slide 49 text

• Early warning to users • Main rules exist • Imports valid SEMANTIC CHECKING

Slide 50

Slide 50 text

• Rule Memoization • Policy Caching • Import Recycling • Sandboxing • Execution time limited • Memory limited • Stack depth limited EVALUATOR

Slide 51

Slide 51 text

• Avoid User Functions • Built in Standard Library • Time, Math, CIDR parsing, Strings, etc STANDARD LIBRARY

Slide 52

Slide 52 text

ENFORCEMENT LEVELS "I'm sorry, Dave. I'm afraid I can't do that"

Slide 53

Slide 53 text

• Different Levels • Runtime aware • Advisory • Soft Mandatory • Hard Mandatory ENFORCEMENT LEVELS

Slide 54

Slide 54 text

• Policy is allowed to fail • Warning is showed to user • “Warn if user provisions deprecated instance type” ENFORCEMENT LEVEL: ADVISORY

Slide 55

Slide 55 text

• Action is blocked when policy fails • Action is allowed when an override is specified • Override is tied to additional permissions • User has explicitly acknowledged out of policy action • “Do not allow changes outside of business hours (unless there is an outage)” ENFORCEMENT LEVEL: SOFT MANDATORY

Slide 56

Slide 56 text

• Action is blocked when policy fails • Override is not possible • “Encryption keys are at least 128 bits and non-exportable” ENFORCEMENT LEVEL: HARD MANDATORY

Slide 57

Slide 57 text

• Multiple policies may be evaluated per action • Smaller policies vs Monolithic policy • Mandatory failures can short circuit RUNTIME AWARENESS

Slide 58

Slide 58 text

• Sentinel Runtime is embedded • In Data Path • Active Enforcement • How to develop and test policies? EMBEDDED FRAMEWORK

Slide 59

Slide 59 text

SENTINEL SIMULATOR

Slide 60

Slide 60 text

Terminal Usage: sentinel [--version] [--help] [] Available commands are: apply Execute a policy and output the result doc Show documentation for an import from a doc file fmt Format Sentinel policy to a canonical format test Test policies version Prints the Sentinel version

Slide 61

Slide 61 text

Terminal $ sentinel apply -trace example_1.sentinel Pass Execution trace. The information below will show the values of all the rules evaluated and their intermediate boolean expressions. Note that some boolean expressions may be missing if short-circuit logic was taken. TRUE - example_1.sentinel:3:1 - Rule "main" TRUE - example_1.sentinel:3:15 - time.hour > 8 TRUE - example_1.sentinel:3:33 - time.hour < 17

Slide 62

Slide 62 text

Terminal $ sentinel apply -trace example_1.sentinel Fail Execution trace. The information below will show the values of all the rules evaluated and their intermediate boolean expressions. Note that some boolean expressions may be missing if short-circuit logic was taken. FALSE - example_1.sentinel:3:1 - Rule "main" FALSE - example_1.sentinel:3:15 - time.hour > 16

Slide 63

Slide 63 text

• Apply allows for playing with policies during development • Test suites • Regression testing TESTING POLICIES

Slide 64

Slide 64 text

Terminal $ tree . ├── example_1.sentinel ├── test │ ├── example_1 │ │ ├── fail.json │ │ └── pass.json

Slide 65

Slide 65 text

{ "config": { ... }, "mock": { "time": { "hour": 9 } }, "test": { "main": false } } pass.json

Slide 66

Slide 66 text

Terminal $ sentinel test -v example_1.sentinel PASS - example_1.sentinel PASS - test/example_1/fail.json trace: FALSE - example_1.sentinel:3:1 - Rule "main" FALSE - example_1.sentinel:3:15 - time.hour >= 16 PASS - test/example_1/pass.json trace: TRUE - example_1.sentinel:3:1 - Rule "main" TRUE - example_1.sentinel:3:15 - time.hour >= 16 TRUE - example_1.sentinel:3:35 - time.hour < 17

Slide 67

Slide 67 text

CONTINUOUS INTEGRATION

Slide 68

Slide 68 text

IMPORT SDK

Slide 69

Slide 69 text

• Infrastructure composed of many pieces • Many policies require external information • Easy to incorporate external state IMPORTS

Slide 70

Slide 70 text

• SDK makes it easy to expose new import • Host systems allow imports to be specified • Configured in advance for security • Plugins use IPC • Runtime multiplexes and garbage collects IMPORT SDK

Slide 71

Slide 71 text

• Integrate common systems • Integrate custom internal systems • Extend with arbitrary logic IMPORT SDK

Slide 72

Slide 72 text

CROSS SYSTEM PROTECTION Submit Service Service Configured?

Slide 73

Slide 73 text

CROSS SYSTEM PROTECTION Delete Service Config Service Running?

Slide 74

Slide 74 text

USE CASES

Slide 75

Slide 75 text

• Infrastructure as Code guardrails • Simplify Compliance • “Fool me once, shame on you.” POLICY AS CODE USE CASES

Slide 76

Slide 76 text

• Define Sandbox • Limits the potential damage of automation • Impose “sanity check” without manual process INFRASTRUCTURE AS CODE GUARDRAILS

Slide 77

Slide 77 text

• Compliance often expressed as Word doc • Codify compliance requirements • Active enforcement simpler than passive detection • “An once of prevention is worth a pound of cure.” SIMPLIFY COMPLIANCE

Slide 78

Slide 78 text

• Policies will never be exhaustive • Memory is finite! • Codify policies to defend against repeat mistakes • Scaling policies easier to expanding memory AVOID REPEAT MISTAKES

Slide 79

Slide 79 text

• Policy as Code builds upon “As Code” • Shared benefits as Infrastructure as Code • Sentinel a framework for Policy as Code • Language, Import SDK OSS • Next Step in Infrastructure Automation CONCLUSION

Slide 80

Slide 80 text

THANKS!