You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: governance/README.md
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -2,6 +2,6 @@
2
2
3
3
Sentinel gives operations teams the governance capabilities they need to ensure that all infrastructure provisioned with Terraform Enterprise complies with their organization's provisioning rules. The files under this directory and its sub-directories provide some sample Sentinel policies for AWS, Microsoft Azure, Google Cloud Platform (GCP), and VMware as well as some cloud-agnostic policies.
4
4
5
-
The policies are grouped into [first-generation](./first-generation) and [second-generation](./second-generation)directories. The first-generation policies were created in 2018 while the second-generation policies were created in 2019. We encourage users to use the second-generation policies and to model new policies on them.
5
+
The policies are grouped into [first-generation](./first-generation), [second-generation](./second-generation), and [third-generation](./third-generation)directories. The first-generation policies were created in 2018. The second-generation policies were created in 2019 and made significant [improvements](./second-generation/README.md#improvements) including better information for resources that violated policies. Both the first-generation and the second-generation policies used the original v1 versions of the tfplan, tfstate, and tfconfig imports. The third-generation policies were created in 2020 and use the v2 versions of those imports. The third-generation policies also use [Sentinel Modules](https://docs.hashicorp.com/sentinel/extending/modules/) which allow the policies to be much shorter than the second-generation policies. You can read more about the important characterizations of the third-generation policies [here](./second-generation/README.md#important-characterizations-of-the-new-policies).
6
6
7
-
If you would like to see an end-to-end process for managing Sentinel policies and policy sets with version control and Terraform Enterprise, see the [hashicorp/tfe-policies-example](https://github.com/hashicorp/tfe-policies-example) repository.
7
+
Note, however, that the v2 imports can only be used with Terraform 0.12 and higher. We encourage users who are only enforcing policies against Terraform 0.12 and higher to use the third-generation policies and to model new policies on them. But if you still need to enforce policies against Terraform 0.11 configurations, then you should use the second-generation policies.
Copy file name to clipboardExpand all lines: governance/third-generation/README.md
+26-12Lines changed: 26 additions & 12 deletions
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,4 @@
1
1
# Third-Generation Sentinel Policies
2
-
3
2
This directory and its sub-directories contain third-generation Sentinel policies and associated [Sentinel CLI](https://docs.hashicorp.com/sentinel/intro/getting-started/install) test cases and mocks which were created in 2020 for AWS, Microsoft Azure, Google Cloud Platform (GCP), and VMware. It also contains some some common, re-usable functions.
4
3
5
4
Additionally, it contains [Policy Set](https://www.terraform.io/docs/cloud/sentinel/manage-policies.html#the-sentinel-hcl-configuration-file) configuration files so that the cloud-specific and cloud-agnostic policies can easily be added to Terraform Cloud organizations using [VCS Integrations](https://www.terraform.io/docs/cloud/vcs/index.html) after forking this repository.
@@ -33,25 +32,27 @@ These new third-generation policies have several important characteristics:
33
32
1. The common function `evaluate_attribute`, which is in the tfplan-functions.sentinel and tfstate-functions.sentinel modules, can evaluate the values of any attribute of any resource even if it is deeply nested inside the resource. It does this by calling itself recursively.
34
33
35
34
## Common Functions
36
-
You can find most of the functions used in the third-generation policies in the Sentinel modules in the [common functions](./common-functions) directory:
You can find most of the common functions used in the third-generation policies in the Sentinel modules in the [common functions](./common-functions) directory:
There are also some functions used to validate assumed roles for the AWS provider in [aws-functions.sentinel](./aws/aws-functions/aws-functions.sentinel).
41
+
There are also some functions used to validate assumed roles for the AWS provider in [aws-functions](./aws/aws-functions).
43
42
44
-
Unlike the second-generation common functions that were each defined in a separate file, all of the common functions that use any of the 4 Terraform Sentinel imports (tfplan/v2, tfstate/v2, tfconfig/v2, and tfrun) are defined in a single file. This makes it easier to import all of the functions that use one of those imports into the Sentinel CLI test cases, since those only need a single stanza such as this one for each module:
43
+
Unlike the second-generation common functions that were each defined in a separate file, all of the common functions that use any of the 4 Terraform Sentinel imports (tfplan/v2, tfstate/v2, tfconfig/v2, and tfrun) are defined in a single file. This makes it easier to import all of the functions that use one of those imports into the Sentinel CLI test cases and Terraform Cloud policy sets, since those only need a single stanza such as this one for each module:
Test cases that use the other modules would either change both occurrences of "tfplan" in that stanza to "tfstate", "tfconfig", or "tfrun" or would add additional stanzas with those changes.
51
+
Test cases that use the other modules would either change all three occurrences of "tfplan" in that stanza to "tfstate", "tfconfig", or "tfrun" or would add additional stanzas with those changes.
52
+
53
+
We have put each Sentinel module in its own directory which also contains Markdown files for each of the module's functions under a docs directory. Each of these Markdown files describes the function, its declaration, its arguments, other common functions it uses, what it returns, and what it prints. It also gives examples of calling the function and sometimes lists some policies that call it.
53
54
54
-
While having multiple functions in a single file and module does make examining the function code a bit harder, we think the reduced work associated with referencing the functions in the test cases justifies this.
55
+
While having multiple Sentinel functions in a single file does make examining the function code a bit harder, we think the reduced work associated with referencing the functions in the test cases and policy sets justifies this.
55
56
56
57
To use any of the functions in a new policy, be sure to include lines like these:
57
58
```
@@ -67,7 +68,7 @@ In this case, we are using `plan`, `state`, `config`, `run`, and `aws` as aliase
67
68
We discuss these two modules together because they are essentially identical except for their use of the tfplan/v2 and tfstate/v2 imports.
68
69
69
70
Each of these modules has several types of functions:
70
-
*`find_resources` and `find_datasources` functions that find resources or data sources of a specific type that are being created or updated.
71
+
*`find_resources` and `find_datasources` functions that find resources or data sources of a specific type that are being created or updated. Note that the tfplan versions of these functions only find resources that are being created or changed and data sources that are being created, changed, or read.
71
72
*`find_resources_being_destroyed` and `find_datasources_being_destroyed` function that find resources or data sources that are being destroyed but not re-created.
72
73
* The `find_blocks` function finds all blocks of a specific type in a single resource.
73
74
*`filter_*` functions that filter a collection of resources, data sources, or blocks to a sub-collection that violates some condition. (When we say resources below, we are including data sources which are really just read-only resources.) The filter functions all accept a collection of resource changes (for tfplan/v2) or resources (for tfstate/v2), an attribute, a value or a list of values, and a boolean, `prtmsg`, which can be `true` or `false` and indicates whether the filter function should print violation messages. The filter functions return a map consisting of 2 items:
@@ -78,6 +79,10 @@ Each of these modules has several types of functions:
78
79
* The `to_string` function which can convert any Sentinel object to a string. It is used to build the messages in the `messages` collection returned by the filter functions.
79
80
* The `print_violations` function which can be called after calling one of the filter function to print the violation messages. This would only be called if the `prtmsg` argument had been set to `false` when calling the filter function. This is sometimes desirable especially if processing blocks of resources since your policy can then print some other message that gives the address of the resource with block-level violations before printing them.
80
81
82
+
Documentation for each individual function can be found in these directories:
### The Functions of the tfconfig-functions Module
82
87
The `tfconfig-functions` module has several types of functions:
83
88
*`find_all_*` functions find all resources, data sources, provisioners, providers, variables, outputs, and module calls of all types.
@@ -89,19 +94,28 @@ The `tfconfig-functions` module has several types of functions:
89
94
* Two filter functions, `filter_attribute_not_in_list` and `filter_attribute_in_list`, that are similar to the filter functions in the tfplan-functions module. However, these can only be used against top-level attributes of the items in the collection passed to them. Those collections can be any type of entity covered by the tfconfig/v2 import including resources, data sources, providers, provisioners, variables, outputs, and module calls.
90
95
* The same `to_string` and `print_violations` functions that are in the tfplan-functions module.
91
96
97
+
Documentation for each individual function can be found in this directory:
The `tfrun-functions` module has the following functions:
94
102
* The `limit_proposed_monthly_cost` function validates that the proposed monthly cost estimate is less than the given limit.
95
103
* The `limit_cost_and_percentage_increase` function validates that the proposed monthly cost estimate and percentage increase over the previous cost estimate ar both less than limits.
96
104
* The `limit_cost_by_workspace_name` function validates that the monthly cost estimate is less than the limit in a map associated with a workspace name prefix or suffix that the current workspace has.
97
105
106
+
Documentation for each individual function can be found in this directory:
The `aws-functions` module (which is located under in the aws/aws-functions directory) has the following functions:
100
111
* The `determine_role_arn` function determines the ARN of a role set in the `role_arn` parameter of an AWS provider. It can only determine the role_arn if it is set to either a hard-coded value or to a reference to a single Terraform variable. It sets the role to "complex" if it finds a single non-variable reference or if it finds multiple references. It sets the role to "none" if no role arn is found.
101
112
* The `get_assumed_roles` function gets all roles assumed by AWS providers in the current Terraform configuration. It calls the `determine_role_arn` function.
102
113
* The `validate_assumed_roles_with_list` function validates assumed roles found by the `get_assumed_roles` function against a list of role ARNs.
103
114
* The `validate_assumed_roles_with_map` function validates assumed roles found by the `get_assumed_roles` function against a map of role ARNs which are associated with regular expressions representing workspace names that are allowed to use them.
104
115
116
+
Documentation for each individual function can be found in this directory:
117
+
*[aws-functions](./aws/aws-functions/docs)
118
+
105
119
## Mock Files and Test Cases
106
120
Sentinel [mock files](https://www.terraform.io/docs/enterprise/sentinel/mock.html) and [test cases](https://docs.hashicorp.com/sentinel/commands/config#test-cases) have been provided under the test directory of each cloud so that all the policies can be tested with the [Sentinel CLI](https://docs.hashicorp.com/sentinel/commands). The mocks were generated from actual Terraform 0.12 plans run against Terraform code that provisioned resources in these clouds. The pass and fail mock files were edited to respectively pass and fail the associated Sentinel policies. Some policies, including those that have multiple rules, have multiple fail mock files with names that indicate which condition or conditions they fail.
This function determines the ARN of an AWS IAM role assumed by the Terraform AWS provider using the [tfconfig/v2](https://www.terraform.io/docs/cloud/sentinel/import/tfconfig-v2.html) and [tfplan/v2](https://www.terraform.io/docs/cloud/sentinel/import/tfplan-v2.html) imports.
3
+
4
+
It can only do this when the `role_arn` of the AWS provider is set to a hard-coded string or to a variable within the Terraform configuration. In the second case, the function cross-references the name of the variable in the tfconfig/v2 import with the actual value assigned to it in the tfplan/v2 import.
5
+
6
+
## Sentinel Module
7
+
This function is contained in the [aws-functions.sentinel](../aws-functions.sentinel) module.
8
+
9
+
## Declaration
10
+
`determine_role_arn = func(address, data)`
11
+
12
+
## Arguments
13
+
***address**: the address of the provider which has the form `module_address:provider.alias`.
14
+
***data**: the data associated with the provider.
15
+
16
+
## Common Functions Used
17
+
None
18
+
19
+
## What It Returns
20
+
This function returns the ARN of the AWS IAM role of the provider. However, if no role was specified for an instance of the AWS provider, it returns "none", and if it finds finds a single non-variable reference or multiple references, it returns "complex".
21
+
22
+
## What It Prints
23
+
This function prints warning messages if the `role_arn` attribute was not a hard-coded string or a reference to a single variable.
24
+
25
+
## Examples
26
+
Here is an example of calling this function, assuming that the [tfconfig-functions.sentinel](../../../common-functions/tfconfig-functions/tfconfig-functions.sentinel) module has been imported with the alias `config`:
This function is called by the `get_assumed_roles` function contained in the same Sentinel module. In fact, the above code is extracted from that function. Since the two functions are in the same module, the call to the `get_assumed_roles` function does not include the `aws.` prefix.
This function gets all roles assumed by any instances of the AWS provider in the current Terraform configuration using the [tfconfig/v2](https://www.terraform.io/docs/cloud/sentinel/import/tfconfig-v2.html) and [tfplan/v2](https://www.terraform.io/docs/cloud/sentinel/import/tfplan-v2.html) imports.
3
+
4
+
The tfplan/v2 import is used by the `determine_role_arn` function that this function calls.
5
+
6
+
## Sentinel Module
7
+
This function is contained in the [aws-functions.sentinel](../aws-functions.sentinel) module.
8
+
9
+
## Declaration
10
+
`get_assumed_roles = func()`
11
+
12
+
## Arguments
13
+
None
14
+
15
+
## Common Functions Used
16
+
This function calls the `find_providers_by_type` function of the [tfconfig-functions.sentinel](../../../common-functions/tfconfig-functions/tfconfig-functions.sentinel) module and the `determine_role_arn` function of the [aws-functions.sentinel](../aws-functions.sentinel) module.
17
+
18
+
## What It Returns
19
+
This function returns a map indexed by the addresses of the provider instances contained in the workspace's Terraform configuration with values set to the actual ARNs of the AWS IAM roles assumed by those providers. However, if no role was specified for an instance of the AWS provider, it returns "none" for that instance, and if it finds finds a single non-variable reference or multiple references for an instance, it returns "complex" for that instance.
20
+
21
+
## What It Prints
22
+
This function does not print anything itself, but the `determine_role_arn` function prints warning messages if the `role_arn` attribute was not a hard-coded string or a reference to a single variable.
23
+
24
+
## Examples
25
+
Here is an example of calling this function:
26
+
```
27
+
assumed_roles = get_assumed_roles()
28
+
```
29
+
30
+
This function is called by the `validate_assumed_roles_with_list` and `validate_assumed_roles_with_map` functions contained in the same Sentinel module. Since the three functions are in the same module, the call to the `get_assumed_roles` function does not include the `aws.` prefix.
***allowed_roles**: a list of allowed AWS IAM role ARNs that can be assumed by AWS providers. If you want to a policy that calls this function to pass if a role assumed by an instance of the AWS provider contains a single non-variable reference or multiple references, include "complex" in the list.
12
+
13
+
## Common Functions Used
14
+
This function calls the the `get_assumed_roles` function of the [aws-functions.sentinel](../aws-functions.sentinel) module.
15
+
16
+
## What It Returns
17
+
This function returns `true` if all the AWS IAM roles assumed by AWS providers in the Terraform configuration of the current workspace were in the `allowed_roles` list. Otherwise, it returns `false`.
18
+
19
+
## What It Prints
20
+
This function prints a warning message for each role assumed by an AWS provider that is not in the `allowed_roles` list.
21
+
22
+
## Examples
23
+
Here is an example of calling this function, assuming that the aws-functions.sentinel file that contains it has been imported with the alias `aws`:
0 commit comments