Policy as Code: IT Governance With HashiCorp Sentinel
•Als PPTX, PDF herunterladen•
1 gefällt mir•7,478 views
Get an updated 2019 introduction to Sentinel, HashiCorp's policy as code framework. See demos of Sentinel policies inside Terraform, Consul, Nomad, and Vault, and learn about upcoming features.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Policy as Code: IT Governance With HashiCorp Sentinel
Ähnlich wie Policy as Code: IT Governance With HashiCorp Sentinel (20)
Mehr von Mitchell Pronschinske
Mehr von Mitchell Pronschinske (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Policy as Code: IT Governance With HashiCorp Sentinel
- 1. Policy as Code: IT Governance With HashiCorp Sentinel Chris Marchesi Engineering Lead, Sentinel HashiCorp
- 2. What is Sentinel? Sentinel is HashiCorp's Policy as Code framework ● Enables IT governance in HashiCorp enterprise products: ○ Terraform Cloud & Enterprise ○ Consul Enterprise ○ Nomad Enterprise ○ Vault Enterprise
- 3. Recap: Infrastructure as Code (IaC)
- 4. Infrastructure as Code at HashiCorp HashiCorp products embody Infrastructure as Code ● IaC is necessary for an organization to scale ● IaC helps by: ○ Versioning your work ○ Providing Automation for your workflows ○ Providing natural Documentation for your processes
- 5. Infrastructure as Code - Versioning Configuration storage with history ● Use VCS systems (git, etc) to store data ● Changes are tracked ● Natural audit trail is produced ● Allows the observation of change to infrastructure over time
- 6. Infrastructure as Code - Automation Simple deployment, complex infrastructure ● Transfer manual workflows to automated ones ● Execute deployments or changes in a single operation ● Vastly reduces amount of manual work necessary ● Reduce possibility for human error ● Deploy at speed and scale not normally possible with manual work
- 7. Infrastructure as Code - Documentation The source is the documentation - no, really! ● Reduces or removes the need for documentation that may be prone to frequent change ● Reduces risk of divergence of documentation from reality ● Can largely replace documentation when it concerns automation
- 8. Terraform Version configuration, and re-usable modules Automate provisioning of complex infrastructure Document infrastructure configuration across your organization Packer, Vagrant Version build workflows and scripts Automate creation of images or development environments Document application dependencies Consul, Nomad, Vault Version services, jobs, and security policies Automate management through CLI and APIs Document service, job, and security components
- 9. Infrastructure as Code at Scale
- 10. Infrastructure as Code at Scale As the organization scales, IaC presents its own challenges ● Increased productivity makes risk management harder ○ Security of the infrastructure and organization ○ Ensuring the organization is in Compliance ○ Ensuring workflows follow Best Practices
- 11. IaC at Scale - Security Security is a fundamental - and important - part of every organization ● Security policies and procedures risk getting lost in growth ● Security awareness is subjective from employee to employee ● Security lapses at scale can have extremely disastrous results (ie: data breaches)
- 12. IaC at Scale - Compliance Industry-mandated security and privacy procedures ● PCI DSS (payment processing) ● Government standards (FIPS - US) ● Privacy standards (GDPR) Violations can affect your business ● Loss of ability to process payments ● Loss of access to certain business sectors ● Financial penalties
- 13. IaC at Scale - Best Practices Generally correct procedures not covered by a specific standard ● No single points of failure ● Optimize for cost efficiency ● Build for a responsive user experience But - "best practice"? Or just "common sense"?
- 14. Policy as Code
- 15. Policy as Code - The Traditional Process Documentation, manual review ● Security/compliance/best practice policies stored in documentation ● Applied by practitioners during code review and dry runs Time-consuming, error-prone, and disempowering ● Code review is a labor and requires context ● Errors can be missed or subjectively accepted as correct ● Review can take days and can lead to frustration
- 16. Policy as Code - IaC for Governance Move your policies to code ● Automate checks and balances ● Remove arbitrary interpretation ● Immediate results for engineers ● Frees up time for everyone The benefits of IaC for your policies ● Version your policies, stored in VCS, with a change history ● Automate policy checks ● Document your policies with code
- 18. Sentinel Fundamentals Policy as code for everyone ● Friendly to Non-Programmers ● Friendly to Programmers ● Embeddable ● Safe ● Auditable
- 19. Friendly to Non-Programmers Programming experience not required ● Emphasis on simple policies ○ We aim to keep policies short and readable ○ Policies are restricted to a single file of code ● English-based grammar ○ Statements, keywords, and operators are english words
- 20. Friendly to Programmers Advanced tools and features to write more complex policies ● Conditionals, loops, functions, and more ● Advanced testing and mocking features ● Growing standard library ○ time - Time access and conversions ○ json - Parse/process JSON data ○ strings - String parsing and manipulation ○ And more!
- 21. Embeddable and Safe Straightforward integration into HashiCorp products ● Embedded directly into runtimes of Consul, Nomad, and Vault Enterprise ● Designed to be efficient and minimize impact to the request path Resilient and Safe ● Broadly read-only language and runtime model ● Restricted system resources
- 22. Auditable Know what rules passed or failed, and why Trace data is retained for rules, including any sub-rules and conditionals Promotes a granular pattern to policy authoring We encourage authors to write policies with many small rules
- 24. import "tfplan" main = rule { all tfplan.resources.aws_instance as _, instances { all instances as _, r { (length(r.applied.tags) else 0) > 0 } } } TERMINAL Terraform Cloud & Enterprise Audit Terraform configuration, diff, and state at plan time Example: A policy that ensures all aws_instance resources in the root module are tagged
- 25. Terraform Cloud & Enterprise - Workflow Enforce policies on select workspaces or entire organization
- 26. Terraform Cloud & Enterprise - Policy Sets Organize policies into VCS-hosted sets that apply to specific workspaces, or to the entire organization
- 27. Terraform Cloud & Enterprise - Mock Generation Generate mock data for offline testing of complex Terraform plans
- 28. Terraform Cloud & Enterprise - Upcoming Features Workspace metadata import Access to Terraform Cloud & Enterprise-specific data, beyond simple config, plan, or state ● Example: Change policy behavior based on org/workspace name Cost estimation import Make policy decisions based on the cost of executing a plan Automatic policy set association Define rules to bind workspaces to policy sets as they are created or modified
- 29. import "time" main = rule when not request.unauthenticated { time.load(token.creation_time).unix > time.load("2017-09-17T13:25:29Z").unix } TERMINAL Vault Enterprise Create policies for: ● Tokens, identity entries, or identity groups ● API endpoint request paths Example: A "kill-switch" endpoint policy that invalidates all tokens created before a certain time
- 30. allowed_drivers = ["docker"] main = rule { all job.task_groups as tg { all tg.tasks as t { t.driver in allowed_drivers } } } TERMINAL Nomad Enterprise ● Restrict job management operations ● Full access to job data ● Soft-mandatory supported Example: Restrict all jobs to using the "docker" task driver
- 31. main = rule { valid_key() } required = [ ["port", "d+"], # ports must be integers ["name", "w+"], # name must be a word ] valid_key = func() { for required as v { if key is v[0] { return value matches v[1] } } return false } TERMINAL Consul Enterprise Extends the standard ACL system beyond read/write/deny Example: Validate input based on the key name
- 33. $ cat time.sentinel import "time" main = rule { time.now.hour > 8 and time.now.hour < 17 } $ date Mon 8 Jul 2019 10:00:00 UTC $ sentinel apply policy.sentinel Pass TERMINAL Try out Policies Try out sample policies locally using sentinel apply Access to entire standard library in default configuration
- 34. $ cat sentinel.json { "mock": { "foo": { "bar": "baz" } } } $ cat policy.sentinel import "foo" main = rule { foo.bar is "baz" } $ sentinel apply policy.sentinel Pass TERMINAL Mock Test Data Mock static data directly in configuration Mock dynamic data using Sentinel code itself
- 35. $ cat sentinel.json { "mock": { "tfplan": "mock-tfplan.sentinel" } } $ cat policy.sentinel main = rule { all tfplan.resources.aws_instance as _, instances { all instances as _, r { (length(r.applied.tags) else 0) > 0 } } } $ sentinel apply policy.sentinel Pass TERMINAL Mocking Terraform Imports Use downloaded mock data to test your policies
- 36. $ tree . ├── policy.sentinel ├── policy2.sentinel └── test ├── policy │ ├── fail.json │ └── pass.json └── policy2 ├── fail.json └── pass.json $ cat policy.sentinel import "foo" main = rule { foo.bar is "baz" } TERMINAL Execute Test Suites Test suites are groups of configuration files residing in a test/POLICY_NAME directory structure
- 37. $ cat test/policy/pass.json { "mock": { "foo": { "bar": "baz" } }, "test": { "main": true } } TERMINAL Execute Test Suites Test configuration files contain the data needed to mock that specific test case, and rule assertions Example: A test for a policy pass case
- 38. $ cat test/policy/fail.json { "mock": { "foo": { "bar": "qux" } }, "test": { "main": false } } TERMINAL Execute Test Suites Mock data can be altered on a per-test basis to test different scenarios Example: A test for a policy failure case
- 39. $ sentinel test PASS - policy.sentinel PASS - test/policy/fail.json PASS - test/policy/pass.json PASS - policy2.sentinel PASS - test/policy2/fail.json PASS - test/policy2/pass.json TERMINAL Execute Test Suites Use sentinel test to run the entire suite of tests Multiple policies can be tested in the same repository
- 40. Download the Simulator Get the simulator at https://docs.hashicorp.com/sentinel/downloads
Hinweis der Redaktion
- Greetings everyone! Today I'm happy to discuss with you all HashiCorp's policy-as-code framework, Sentinel. Whether or you're completely new to Sentinel or not, I hope that this presentation can help you get more familiar with the framework and its role in our enterprise products. I'm Chris Marchesi, engineering lead for Sentinel at HashiCorp, and a primary developer for the Sentinel runtime and its integrations, namely Terraform Cloud and Enterprise.
- Let's start with a brief on what Sentinel actually is. Sentinel is HashiCorp's policy as code framework, introduced at HashiConf 2017. It enables IT governance in HashiCorp's enterprise products. You will see integrations in Terraform Cloud and Enterprise, Consul Enterprise, Nomad Enterprise, and Vault Enterprise. Today, I'd like to give everyone here a general tour of the framework, to help you, the practitioner, get an idea of the kinds of problems Sentinel was designed to solve, how it works with our products, and how you can get started using it today.
- So, what exactly do we mean when we say Sentinel is a policy as code product? In order to better explain what policy as code is, let's start by building some context and discuss the well-established concept of infrastructure as code. This will give us a foundation which we can build on and make it even more obvious as to why policy as code is necessary when working with IaC at scale.
- At HashiCorp, we're firm believers of the concept of infrastructure as code. We'd like to think that our products embody the practice. We believe that investing in IaC is necessary for an organization to scale. It can be very rewarding in its own right to practitioners of a wide variety of backgrounds. Let's dive into a bit more about what we mean here by discussing how IaC helps by versioning your work, providing automation for your workflows, and finally providing natural documentation for your processes. While not necessarily the whole of IaC, we believe that these disciplines are at the heart of the concept.
- Let's start with versioning. Versioning is the foundation of the infrastructure as code concept, giving you configuration storage with history. It's the practice of using VCS systems, such as git, to store configuration data. These changes are tracked. The VCS history will tell you who made any change, exactly what they changed, and when they changed it. This means that a natural audit trail is produced. This all allows for the observation of change to infrastructure over time. A VCS system, while generally designed for developers, turns out to be a great way to ensure systems engineers can keep track of the modifications they are making, keep them on hand for backups or re-deployments, and roll them back if need be.
- Next, let's move on to automation. The object of automation in IaC is to support a simple deployment workflow to complex infrastructure. Automation is important as it ensures IaC provides value over basic documentation and manual procedures. We transfer manual workflows to automated ones. We aim to execute deployments or changes in a single operation, or at least aim to reduce the number of steps required. This process vastly reduces the amount of manual work necessary, and reduces the possibility for human error. Ultimately, automation enables us to deploy at a speed and scale not normally possible with manual work. Extremely complex operations that would normally take hours could take minutes or even seconds, and that entire workflow can now be repeated hundreds or thousands of times trivially.
- Finally, let's talk about documentation. I think I'd be hard pressed to think of any organization that is perfect with theirs. All too often, workflows adopted by individuals may go undocumented since writing good documentation takes time, and is highly susceptible to drift as situations change. IaC solves this problem by making the source the documentation. While usually said tongue-in-cheek as a criticism in software development, it actually works quite well when applied to infrastructure. It reduces or removes the need for documentation that may be prone to frequent change. It reduces the risk of divergence of documentation from reality, and can largely replace documentation when it comes to automation.
- Every HashiCorp product implements the concepts that we've just discussed to some degree. As IaC tools at heart, Terraform, Packer, and Vagrant are industry leaders when it comes to provisioning of multi-cloud infrastructure, images, or development environments. And while Consul, Nomad, and Vault are not specifically IaC tools themselves, their designs still make it easy to version configuration, automate management, and self-document their particular problem domains.
- Now that we have some of the background on infrastructure as code, let's take a look at some of the challenges that may arise when applying these principles within large organizations.
- Infrastructure as Code is great because it allows you to scale. It reduces the barrier to entry through automation, in addition to just flat out allowing people to do more. But as the organization scales, IaC presents its own challenges. The increase of productivity inherent in automation makes risk management harder. It can put pressure on the teams who are responsible for managing risk within the organization. This can make it hard to effectively manage security of the infrastructure within the organization, ensuring the organization is in compliance, and ensuring workflows follow best practices. Let's take a look at why these things are important.
- Let's talk about security first. Security is a fundamental and important part of every organization. As an organization scales, there's always the risk that security policies and procedures may get lost in the growth. Security awareness is subjective from employee to employee. Through no fault of their own, an individual may unintentionally perform an action that could expose the organization's infrastructure to vulnerabilities. Even security awareness training may not account for every scenario, most notably good old fashioned human error. And security lapses at scale can have extremely disastrous results. As an organization scales, so do the stakes. Data beaches at large organizations are usually newsworthy events, with possibly millions of clients being put at risk, and can create damage to a company's reputation that can take years to repair.
- Hand in hand with security is compliance. Security and privacy procedures usually take the form of industry-mandated policies. Examples include payment processing standards such as the PCI DSS, various government standards such as the FIPS standards in the United States, and data privacy standards such as the GDPR. Violation of these standards can affect your business. Violate PCI, and you may no longer be able to process payments for major credit cards. Violate government standards, and you may not be able to do business with that respective government. Violate GDPR, and you could face fines - which could be in the tens of millions of euros. All practitioners should be aware and receive the appropriate training, but as with security, not everyone is going to have the same level of awareness in general regarding these sensitivities. As the organization grows, it becomes increasingly harder to manage this at the human level.
- Finally, there's the concept of best practices. These aren't necessarily hard and fast security policies, or privacy standards like the GDPR. These are things that are generally correct procedures that are not covered by a specific standard. Examples would be to not set up single points of failure, optimize for cost efficiency, or build for a responsive user experience. But "best practice" can be a fallacy. I personally have a problem with the term, because "best practice" and "common sense" are used interchangeably too often. This leads to assumptions about an individual's awareness. You could easily swap out "it's just best practice" with "it's just common sense" when discussing engineering for redundancy, or managing cost and user experience. And after the fact, such as in a post-mortem, hindsight is very much 20/20 in these matters. These problems are aggravated at scale. As an organization takes on staff, it will also take on a wider variance in awareness levels and opinions as to what actually constitutes "best practice".
- So, how do we solve these policy issues? How do we make sure that we eliminate the assumption that everyone knows how to configure a redundant or performant infrastructure, that adheres to industry standards and government regulations, and does not make the organization vulnerable? Let's talk a bit about policy as code.
- Let's talk about a traditional process first. This is mainly the process of using documentation for manual review. In a manual process, security, compliance, and best practices are stored within documentation as policies to be followed. These are then applied by practitioners during code review, or during operational dry runs such as reviewing the output of a Terraform plan. When we refer to manual application, we are saying that the reviewer follows the policy when making judgements on whether or not to allow a change. The issues here are three-fold. First off, code review is a labor and requires context. This can be tough if the domain experts for the code review are on one team, and the experts on security and compliance are on another. Reviews take enough time already and these kinds of issues can exacerbate them. Also, errors can be missed or subjectively accepted as correct. No one reviewer is the same and sometimes there can be a number of factors at play in addition to the aforementioned context issue. Finally, review can take days and can lead to frustration for the practitioner. This can be a disempowering process and risks negating the gains that adopting infrastructure as code gets you.
- Hence, why policy as code is important too. Moving your policies out of documentation and into code allows you to automate these checks and balances, remove arbitrary interpretation, supply immediate results for engineers, and frees up more time for everyone to do more of the work that they are good at and enjoy doing. Further to that, our policies now enjoy the same benefits as our infrastructure code: you version your policies and store them in VCS with a change history. You automate your policy checks as part of your automated testing process. And finally, you document your policies with code, replacing a good part of your on-paper policy.
- So let's talk about the things that we've been trying to do with Sentinel at HashiCorp to help make policy as code a good experience for everyone.
- Our objective when designing Sentinel was to bring infrastructure as code principles to the governance, risk, and compliance field. This meant bringing over a lot of people that were not programmers. As such, we aimed to design a language that would be both friendly to non-programmers and programmers alike. In addition, we aim for Sentinel to be able to be embeddable - that is, easy to integrate into all of our products, safe - so that it can be executed in a sensitive context, and finally, auditable - so that it's clear as to why a policy has passed or failed.
- Let's elaborate on these fundamentals. First off, we aim to design Sentinel in a way that programing experience is not required to work with the product. As just mentioned, we are working with an audience that is composed significantly of non-programmers. They may have experience in what needs to happen to adhere to compliance standards, or may have more of a traditional systems administration background. As practitioners of Sentinel, we want these audiences to be able to be able to understand policies written in the language, and even be able to write them to a level of complexity. We aim to keep the language understandable to non-programmers via a couple of principles. The first is an emphasis on simple policies. The language and integrations are extended with the objective of keeping policies short and readable. In addition, policies are restricted to a single file of code. This makes it all the more obvious when we need to make changes to the runtime or any integrations to ensure we are keeping in line with this principle. Secondly, we use an english-based grammar. Most statements, keywords, and operators are english language words, structured in a way that reads something between pseudocode, and actual english-language sentences.
- At the same time, we still aim to make Sentinel friendly to programmers. Stakeholders with programming or even at least scripting experience will be able to write more complex policies than those that don't have a similar background. Sentinel has constructs that a programmer would reasonably expect such as conditionals, loops, and the ability to create functions to help with more complex workflows. The Sentinel simulator also has advanced testing and mocking features that we will cover in the later part of this presentation. These features allow practitioners to mimic the environments that they will encounter in production to ensure policies function correctly. To help with processing the wide variety of data that can be encountered in Sentinel, we also have a growing standard library that we are building on all the time. Some of the imports available in the standard library include the time import for accessing the time of day, the json import for parsing JSON data, and the strings import for parsing and manipulating strings within Sentinel. These are not all of the imports of course - you can find these and more on the Sentinel website.
- Let's talk a bit about how we design Sentinel internally to be embeddable and safe to the products it's integrated into. Internally, we design Sentinel with the principle of straightforward integration into HashiCorp products. It's embedded directly into the runtimes of Consul, Nomad, and Vault Enterprise. With Sentinel being invoked in time-critical places in these products, we have designed it to be efficient and minimize impact to the request path. This level of embedding also means that we need Sentinel to be resilient and safe. We have designed a broadly read-only language and runtime model as the intention of Sentinel is to analyze data, not change it. We also give restricted system resources to the runtime - this prevents Sentinel from causing a resource exhaustion that could crash a system. There is also no ability in the runtime or the standard imports that allow arbitrary commands to be executed.
- Finally, Sentinel is designed to be auditable, so that you know what rules passed or failed, and why. Trace data is retained for rules, including any sub-rules and conditions that triggered a specific result. This data is built naturally as rules are evaluated in a policy. This promotes a more granular pattern for policy authoring. We encourage authors to write policies with many small rules to take full advantage of auditing functionality.
- Sentinel has been implemented in every HashiCorp product at varying levels of scale, but has probably seen its most extensive deployment to date in Terraform Cloud and Enterprise. Let's take a look at each of these implementations, including what a policy may look like in each implementation and some of the features that are offered with Sentinel in each of these products.
- Here is an example of what a policy looks like within Terraform Cloud and Enterprise. In this example, we use data from a Terraform plan, provided by an import that provides the plan data, aptly named "tfplan". This example would traverse all aws_instance resources defined in the root module and ensure that all instances will have tags defined. If a resource is detected that does not have tags, the policy fails, and the run is blocked.
- Sentinel policy checks run in Terraform Cloud and Enterprise immediately after a plan has been made. This phase - called the policy check - is sent the plan, along with the configuration and any existing previous state. You make a policy based off of this data, with the results ultimately determining if the plan can or cannot proceed. You can also use the soft-mandatory result to require that a plan proceed only with approval from an organization administrator.
- Policies are organized in Terraform Cloud and Enterprise by way of policy sets, which have recently been updated to adopt a completely VCS-hosted pattern. These function in a similar fashion to workspaces in that policies are ingressed as they are added or modified on the source VCS repository. You choose to apply these policies to select workspaces, or to the organization as a whole. When a run executes, policies from all applicable sets are collected and sent for execution in the policy check for that run. Which policies are executed, along with each of their enforcement levels, are controlled from within a HCL-based configuration file in the policy set repository.
- Being able to test your policies before they get deployed to a policy set is an important part of the development process. Testing policies live can be tedious, so we provide the tools to allow you to test policies offline before deployment. We will discuss testing in detail later. An important part of offline testing is the ability to work with mock data. The data that comes from Terraform Cloud and Enterprise is very complex and mocking each particular scenario can be hard without access to actual data. To help ease this, we allow the capabilities to generate mock data off of any existing Terraform plan. Whether you need an initial data set to work off of, or a copy of existing configuration data to account for a certain scenario, mock generation gives you the confidence that you are working with exactly the data you need to work with.
- Finally, let's discuss some upcoming features that we will be implementing in the Sentinel integration within Terraform Cloud and Enterprise. The first is the what we are currently calling the workspace metadata import. This import will complement the current Terraform imports by supplying you with access to Terraform Cloud and Enterprise-specific data, beyond the simple config, plan, or state. This will include data specific to the run, workspace, or organization. For example, you could change the behavior of a policy via the name of the organization or workspace that it was a part of. The second is the integration of cost estimation data into Sentinel. This means you will be able to make policy decisions based on the cost of executing a plan. Lastly, we will be working to reduce the burden on workspace management by allowing automatic policy set association with workspaces. Through rules defined on a workspace, policy sets will be automatically associated with workspaces as they are added, or even as the rules change on a policy set itself.
- Now let's see what a policy looks like in Vault Enterprise. Sentinel support in Vault Enterprise complements the existing ACL system with the addition of two new types of policies. Role Governing Policies - or RGPs, are tied to particular tokens, Identity entities, or Identity groups. Endpoint Governing Policies - or EGPs, are tied to paths instead of tokens. During a specific request in Vault Enterprise, all three policy types are evaluated, starting with conventional ACLs, and then moving onto the Sentinel RGPs, and then EGPs, in that order. The first two policies are only evaluated if the request is authenticated, which means that Sentinel and endpoint policies are the only way to perform checks independent of authentication data. Here, we have an example of an EGP demonstrating the instant invalidation of all tokens that have been created before a specific time. This can be used as a kill-switch of sorts in the event of a large-scale compromise to ensure that no old tokens are allowed, buying time for forensic analysis and targeted remediation. Similar measures in the conventional ACL system would require a policy that can be modified so that it is attached to every token, in addition to not being applicable to login or otherwise unauthenticated paths.
- Let's move on to Nomad Enterprise. Sentinel policies in Nomad Enterprise allow you to hook into the job management process during operations such as job creation or modification. Access to the full job structure is given, allowing deep introspection into any job configuration file. In addition to this, Nomad Enterprise fully supports soft-mandatory policies. When the appropriate capability is assigned to a user, job submissions that would normally fail can be forced to proceed by supplying the -policy-override flag in the Nomad CLI, or via a similar parameter in the specific API request. Here, we have a policy that ensures that all task groups in a job are using the Docker driver, blocking any other type of job. This would ultimately mean that all the jobs that were run with this policy would have to be Docker containers.
- Finally, we have Consul Enterprise. Sentinel in Consul Enterprise extends the standard ACL system for the key/value store past the standard read, write, and deny policies, allowing full conditional logic and access to the data being written. Here, we have a policy that checks the key being written to, and then validates the input - if we are storing the port, it must be an integer, and if we storing the name, it must be a word - so, specifically, a contiguous series of unicode characters, digits, and connectors.
- To close out the discussion today, let's talk about the Sentinel Simulator. The simulator packages the entire core runtime into a CLI tool that assists in developing and testing Sentinel policies. Whether you are an existing enterprise customer or a practitioner looking to give Sentinel a try, the simulator is an important part of your workflow.
- Using the Sentinel Simulator, you can try out sample policies with the apply sub-command to see if they pass or fail. Here, we try a simple policy testing the functionality of the time standard import. As the simulator comes with the standard library, it's a convenient way to try out the various features so that you know how to use them in practice.
- The simulator would not be entirely effective if it was just able to utilize the standard library. As such, the simulator has capabilities that allow you to simulate the environments seen in HashiCorp's products. Here we see a basic example that verifies a simulated import. The data is supplied as a static object directly within the JSON configuration file. In addition to being able to supply mocks as static data, the Sentinel Simulator also provides the ability to supply mocks as Sentinel code. This allows you to mock data that JSON cannot accurately represent, or other features such as functions.
- Here's an example utilizing the previously mentioned mock data supplied from Terraform Cloud and Enterprise. We don't show the contents of the mock data file as they are generally pretty large. Instead of the object, the path to the mock data file is supplied. Utilizing this more powerful mocking feature is crucial to the accurate mocking of Terraform data and the entirety of the import.
- Finally, I'd like to take a little bit more time covering the Sentinel Simulator's testing feature. The Sentinel Simulator can be used to conduct sophisticated testing comprising of multiple tests across multiple policies in a repository. Here, we've laid out an example repository with two policies. Within the repository is a directory named test, and within the test directory are two sub-directories - eached named for both of the policies. This is where we place our tests. Here, we have passing and failing test files for both of the policies shown.
- Each configuration file can not only assert different results for specific rules, but can also contain different configurations for mock data, ensuring that you can test your policies against as many scenarios as needed to be assured that the policies will behave as expected. This is the passing test, with the import mocked as expected by the policy, and an assertion that the main rule will return a true result. For a more sophisticated policy, you would want to add all of your rules and their appropriate assertions.
- As mentioned, you can mock the data as you see fit for each test case. This is the failing test, where we've adjusted the mock data in a way so that we now expect the policy to fail, which is reflected in the assertion of false for the main rule.
- To run the entire test suite, you run "sentinel test". This will run tests for all of the policies that are found in the working directory. Being able to test not only against multiple cases, but also multiple policies at once in a single repository, is especially useful when working with things such as policy sets in Terraform Cloud and Enterprise.
- The Sentinel simulator is free to use and available on the Sentinel website. It's available to use on all major platforms, including Windows, MacOS, and Linux.
- And that's it! If you'd like to learn more about Sentinel, you can read all about it on our documentation page, at https://docs.hashicorp.com/sentinel. If you'd like to know more at the conference, feel free to come by one of our booths. If you are interested in getting a more in-depth demo with Sentinel on any HashiCorp product, you can contact sales at https://www.hashicorp.com/go/sentinel-demo. Again, I'm Chris Marchesi, engineering lead for Sentinel, and it's been my pleasure to present this to you today. Thank you!