Merge bicep to working.

.devcontainer/Dockerfile

@@ -6,15 +6,15 @@ FROM ubuntu:20.04
 ENV DEBIAN_FRONTEND=noninteractive
 
 # Terraform, providers and tflint versions
-ARG TERRAFORM_VERSION=1.0.3
-ARG AZURERM_VERSION=2.69.0
+ARG TERRAFORM_VERSION=1.0.5
+ARG AZURERM_VERSION=2.73.0
 ARG RANDOM_VERSION=3.1.0
 ARG TIME_VERSION=0.7.2
-ARG TFLINT_VERSION=0.30.0
-ARG TFLINT_AZURERM=0.11.0
+ARG TFLINT_VERSION=0.31.0
+ARG TFLINT_AZURERM=0.12.0
 
 # Azure CLI version
-ARG AZURE_CLI_VERSION=2.26.1-1~focal
+ARG AZURE_CLI_VERSION=2.27.2-1~focal
 
 # Update distro (software-properties-common installs the add-apt-repository command)
 RUN apt-get update \

.github/CODEOWNERS

@@ -0,0 +1,2 @@
+# This group is the default set of reviewers for PRs to main.
+@Azure/mission-lz-reviewers

.github/ISSUE_TEMPLATE/issue.md → .github/ISSUE_TEMPLATE/backlog_item.md

@@ -1,6 +1,6 @@
 ---
-name: Issue
-about: Use issues for planned work
+name: Backlog item
+about: Use backlog items for planned work
 title: ''
 labels: ''
 assignees: ''
@@ -15,4 +15,4 @@ assignees: ''
 
 **Acceptance Criteria**
 - 
--
+- 

.gitignore

@@ -9,6 +9,14 @@ terraform-provider-azurerm_v*
 terraform-provider-random_v*
 *.terraform.lock.hcl
 
+# Terraform logs
+crash.log
+
+# Include tfplan files to ignore the plan output of command: terraform plan -out=tfplan
+# example: *tfplan*
+*plan*
+*.plan*
+
 # Setup config variables file
 mlz.config
 saca-hub.tfvars.json

CONTRIBUTING.md

@@ -51,8 +51,8 @@ These roles demonstrate how we think about doing the work. A single person can o
 
 ### Artifacts
 
-- Product backlog: The product backlog is defined using GitHub issues. Issue templates are in the repo for Issues (new development) and bugs. Backlog items (issues and bugs) are grouped into releases and prioritized within each release. See the [product owner process](#product-owner-process) for more details.
-- Monthly releases: Each release is defined using a GitHub project. One release is finished each month. We plan major themes for each release, but the actual content of a finished release depends on what is accomplished using our Kanban process.
+- Product backlog: The product backlog is defined using GitHub issues. [Issue templates](.github/ISSUE_TEMPLATE) are in the repo for [backlog items (new development) and bugs](https://github.com/Azure/missionlz/issues/new/choose). Issues are grouped into releases and prioritized within each release. See the [product owner process](#product-owner-process) for more details.
+- Monthly releases: Each release is defined using a GitHub project. GitHub projects are visible on the [Projects](https://github.com/Azure/missionlz/projects) tab of the GitHub site. One release is finished each month. We plan major themes for each release, but the actual content of a finished release depends on what is accomplished using our Kanban process.
 - Software increment: Each change to the software is implemented as a git commit to the main branch. GitHub pull requests are used to define and review each commit to main as a squashed merge (all changes combined into a single commit.) See the [development process](#development-process) for more details.
 
 ### Events
@@ -64,9 +64,9 @@ These roles demonstrate how we think about doing the work. A single person can o
 
 ### Development Process
 
-#### Select an Issue
+#### Select a Backlog Item
 
-Team members select issues to develop. More than one member can work on a single issue, and pair programming and other collaboration is encouraged. Generally, issues that have higher priority should be done before lower priority issues, but any issue may be selected from the backlog by any team member.
+Team members select backlog items or bugs to develop. More than one member can work on a single issue, and pair programming and other collaboration is encouraged. Generally, issues that have higher priority should be done before lower priority issues, but any issue may be selected from the backlog by any team member.
 
 #### Create a Branch
 
@@ -86,9 +86,11 @@ Multiple PRs can be created for an issue, but there is usually a single pull req
 
 A draft PR can be used to request feedback from the team.
 
+A [`CODEOWNERS`](https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/creating-a-repository-on-github/about-code-owners) file defines the set of default reviewers for PRs to main.
+
 #### Review Other PRs
 
-When PRs are requested, review each change and run full test deployment, specifically focused on the areas that have changed. Provide comments and feedback directly related to the PR.
+When PRs are requested, review each change and run a full test deployment, specifically focused on the areas that have changed. Provide comments and feedback directly related to the PR.
 
 #### Ensure Quality
 
@@ -98,24 +100,20 @@ The main branch is always production quality. The PR reviewer is responsible for
 
 #### Product Backlog
 
-The backlog is defined in the form of GitHub issues, including bugs and regular issues. Any team member or external stakeholder can author a backlog item. The product owner is responsible for ensuring that all backlog items in a release meet the standards of being ready for development. The standards include:
+The backlog is defined in the form of GitHub issues, including bugs and backlog items. Any team member or external stakeholder can author a backlog item. The product owner is responsible for ensuring that all backlog items in a release meet the standards of being ready for development. The standards include:
 
 - A clear title
-- A concise benefit/result/outcome that defines the benefit someone would receive when the issue is completed.
+- A concise benefit/result/outcome that defines the benefit someone would receive when the issue is completed
 - An optional tag that defines who will benefit from the issue being completed
-- A detailed description that contains more context and may contain implementation details.
-- A full list of acceptance criteria that clearly define when the issue is complete.
-- Scope that is as small as possible and is also a complete and useful new feature for a stakeholder.
+- A detailed description that contains more context and may contain implementation details
+- A full list of acceptance criteria that clearly define when the issue is complete
+- Scope that is as small as possible and is also a complete and useful new feature for a stakeholder
 
 #### Triage
 
 The product owner is responsible for ensuring that each issue is fully triaged and is either closed or added to a release backlog. Triage with the team primarily happens at the weekly planning meeting and can also happen via GitHub as comments within an issue.
 
-When new issues are added to the GitHub issues list, the product owner makes sure that a `needs triage` label is added so that the issue will be discussed in the next planning meeting.
-
-#### Release Definition
-
-The product owner defines the releases in the form of GitHub projects. One release is defined per month. Each release has one or more themes. The themes are reviewed and agreed upon by the team during the weekly planning meeting.
+When new issues are added to the GitHub issues list, the product owner ensures that a `needs triage` label is added so that the issue will be discussed in the next planning meeting.
 
 #### Weekly Planning Meeting
 
@@ -128,10 +126,14 @@ The product owner sets the agenda for the meeting. The agenda includes:
 
 #### Backlog Prioritization
 
-The product owner is responsible for ensuring that the backlog items are prioritized within each release. Setting priority is a collaborative effort by the team. Priority is defined by the stack rank order of the "To do" column in a release.
+The product owner is responsible for ensuring that the backlog items are prioritized within each release. Setting priority is a collaborative effort by the team and usually happens during the weekly planning meeting. Priority is defined by the stack rank order of the "To do" column in a release.
 
 #### Architecture
 
 The product owner is responsible for ensuring that enough architecture documentation exists for the development team and stakeholders. Developing the architecture is a collaborative effort with the rest of the team. Any team member may contribute to the architecture, and some issues may be added to the backlog for discovery and testing in order to determine the elements of the architecture.
 
+#### Release Definition
+
+The product owner defines the releases in the form of GitHub projects. One release is defined per month. Each release has one or more themes. The themes are reviewed and agreed upon by the team during the weekly planning meeting.
+
 **Thank You!** - Your contributions to open source, large or small, make projects like this possible. Thank you for taking the time to contribute.

README.md

@@ -67,7 +67,7 @@ See the [Projects](https://github.com/Azure/missionlz/projects) page for the rel
 Here's what the repo consists of as of May 2021:
 
 <!-- markdownlint-disable MD033 -->
-<img src="src/docs/images/missionlz_as_of_may2021.png" alt="Mission LZ as of April 2021" width="600" />
+<img src="src/docs/images/missionlz_as_of_july2021.jpg" alt="Mission LZ as of July 2021" width="600" />
 <!-- markdownlint-enable MD033 -->
 
 ## Contributing

src/docs/command-line-deployment.md

@@ -101,6 +101,7 @@ deploy.sh: create all the configuration and deploy Terraform resources with mini
            --write-output -w [OPTIONAL] Tier 3 Deployment requires Terraform output, use this flag to write terraform output
              --no-bastion    [OPTIONAL] when present, do not create a Bastion Host and Jumpbox VM
             --no-sentinel    [OPTIONAL] when present, do not create an Azure Sentinel solution
+                 --policy    [OPTIONAL] when present, create Policy Assignments for built-in NIST initiative
    --no-service-principal    [OPTIONAL] when present, do not create an Azure Service Principal, instead use the credentials in the environment variables '$ARM_CLIENT_ID' and '$ARM_CLIENT_SECRET'
               --help -h Print this message
 ```

src/docs/policies.md

@@ -0,0 +1,59 @@
+# Mission Landing Zone Regulatory Compliance - NIST Policies
+
+As part of Mission Landing Zone (MLZ) it's been a goal to ensure deployments have the tools and resources available that allow it to be compliant with most regulations across industries. This does not mean that workloads are compliant, but it does mean that the technologies in use can be compliant. This is caused by not only the varying number of compliance bodies involved and and the regulations they mandate but also caused by the decisions required by how and what controls are followed.
+
+For the purposes of this documentation we created an example method in which the MLZ deployment can be audited for current National Institute of Standards and Technology (NIST) controls and requirements using [Azure Policies built in initiative](https://docs.microsoft.com/en-us/azure/governance/policy/samples/nist-sp-800-53-r4) for NIST 800-53. _Note: this is focused on NIST controls that have built in policies in Azure clouds._
+
+By adding the `--policy` switch to the deployment command the script will multiple assignments to the deployment final architecture. The result is for each Tier (Hub, Tier0, Tier1, and Tier2) there will be an additional policy/initiative assigned scoped to those recourse groups. This will not impact other policies/initiatives assigned that are deployed at different scopes either prior to deploying MLZ or post deployment.
+
+![](images/20210419_missionlz_as_of_Aug2021_Policy.png)
+
+## Known Issues
+
+Currently there are a set of known issues with this approach. The first and somewhat important detail is that these policies are based on built in policies available in the different Azure environments. There are some variances currently between clouds. This will always happen when separate isolated environments have different deployment cycles but also can be based on preview testing versus generally available components in one cloud environment versus another.
+
+A secondary issue comes from the method in which the assignment is deployed. This results in 'out of band' requirements for customers. In particular, the current built-in NIST initiative has a couple policies attached that modify and/or deploy if a resource doesn't exist. Example, VM extensions for guest policy configuration would be deployed if they don't exist in the VM. These types of policies require a managed identity be created that the Policy engine can use to take these actions. This managed identity must have contributor access to the resources but deploying as a contributor and not owner limits the ability. The terraform MLZ deployment as it is today using service principles with contributor rights cannot make this role assignment but the managed identity is created. This is by design for security purposes.
+
+The final note is that these are audits based on NIST controls and recommendations that will require out of band work. As an example, storage account redundancy and encryption will require a decision process on what MLZ is using as temporary storage for logs versus requirements for the workloads. For example, encryption can be accomplished with multiple key models, which one is required for what category of data?
+
+## Deploying
+
+Deploying policy assignments for NIST along with a standard deployment of MLZ is as simple as adding the –policy switch to the deployment script command. This will add a separate assignment of the built in NIST initiative per resource group in the deployment, excluding the resource groups used as deployment artifacts like state and config.
+
+Example:
+ `src/scripts/deploy.sh -s <subscriptionID> -l usgovvirginia --tf-environment usgovernment –policy`
+
+After the resources are deployed, you will need to go into go into each assignment and retrieve the managed identity and modify its role access to contributor scoped to the associated resource group. This is due to the initiative including modify and deploy policies that act on resources, like deploying the require policy guest configuration extensions to VMs.
+
+Modifying
+
+This model uses an additional custom terraform module called 'policy-assignments'. This can be modified for adding additional initiatives if desired. The module deployments retrieve their parameter values from a local json file stored in the module directory named 'nist-parameter-values' and named after the cloud environment they are deploying to, public or usgovernment.
+
+Example parameters file snippet:
+```
+{
+    "listOfMembersToExcludeFromWindowsVMAdministratorsGroup": 
+    {
+      "value": "admin"
+    },
+    "listOfMembersToIncludeInWindowsVMAdministratorsGroup": 
+    {
+      "value": "azureuser"
+    },
+    "logAnalyticsWorkspaceIdforVMReporting": 
+    {
+      "value": ${jsonencode(laws_instance_id)}
+    },
+    "IncludeArcMachines": 
+    {
+        "value": "true"
+    }
+```
+
+In the above example the 'logAnalyticsWorkspaceIdforVMReporting' is retrieved from the running terraform deployment variables. This could be modified to use a central logging workspace if desired.
+
+What's Next
+
+While this is only a start, the NIST controls included in the built-in initiatives are a good start to understanding requirements on top of MLZ for compliance. In the near future the hopes are for this to be expanded with additional built-in initiatives as well as offering an option to create your own initiative and custom policies. Potential additions will be server baselines, IL compliances, and custom policies.
+
+Also scripts to assist in these out-of-band processes will be added.

src/scripts/config/create_mlz_config_resources.sh

@@ -167,13 +167,19 @@ else
         # Assign Contributor Role to Subscriptions
         for sub in "${subs[@]}"
         do
-            echo "INFO: setting Contributor role assignment for ${sp_client_id} on subscription ${sub}..."
+            echo "INFO: setting Contributor and Policy Contributor role assignments for ${sp_client_id} on subscription ${sub}..."
             az role assignment create \
                 --role Contributor \
                 --assignee-object-id "${sp_object_id}" \
                 --scope "/subscriptions/${sub}" \
                 --assignee-principal-type ServicePrincipal \
                 --output none
+            az role assignment create \
+                --role 'Resource Policy Contributor' \
+                --assignee-object-id "${sp_object_id}" \
+                --scope "/subscriptions/${sub}" \
+                --assignee-principal-type ServicePrincipal \
+                --output none
         done
     else
         error_log "ERROR: A service principal named ${mlz_sp_name} already exists. This must be a unique service principal for your use only. Try again with a new mlz-env-name. Exiting script."

src/scripts/deploy.sh

@@ -36,6 +36,7 @@ show_help() {
   print_formatted "--no-bastion" "" "[OPTIONAL] when present, do not create a Bastion Host and Jumpbox VM"
   print_formatted "--no-sentinel" "" "[OPTIONAL] when present, do not create an Azure Sentinel solution"
   print_formatted "--no-service-principal" "" "[OPTIONAL] when present, do not create an Azure Service Principal, instead use the credentials in the environment variables '\$ARM_CLIENT_ID' and '\$ARM_CLIENT_SECRET'"
+  print_formatted "--policy" "" "[OPTIONAL] when present, create Policy Assignments for built-in NIST initiative"
   print_formatted "--help" "-h" "Print this message"
 }
 
@@ -155,7 +156,7 @@ create_mlz_resources() {
 
 create_terraform_variables() {
   echo "INFO: creating terraform variables at ${tfvars_file_path}..."
-  "${this_script_path}/terraform/create_tfvars_from_config.sh" "${tfvars_file_path}" "${mlz_config_file_path}" "${create_bastion_jumpbox}" "${create_sentinel}"
+  "${this_script_path}/terraform/create_tfvars_from_config.sh" "${tfvars_file_path}" "${mlz_config_file_path}" "${create_bastion_jumpbox}" "${create_sentinel}" "${create_assignment}"
 }
 
 apply_terraform() {
@@ -194,6 +195,7 @@ default_env_name="mlz${timestamp}"
 create_bastion_jumpbox=true
 create_sentinel=true
 create_service_principal=true
+create_assignment=false
 
 mlz_config_subid="${default_config_subid}"
 mlz_config_location="${default_config_location}"
@@ -239,6 +241,8 @@ while [ $# -gt 0 ] ; do
       create_sentinel=false ;;
     --no-service-principal)
       create_service_principal=false ;;
+    --policy)
+      create_assignment=true ;;
     -h | --help)
       show_help
       exit 0 ;;

src/scripts/terraform/create_tfvars_from_config.sh

@@ -17,7 +17,7 @@ error_log() {
 
 usage() {
   echo "create_tfvars_from_config.sh: generate a terraform tfvars file given an MLZ config and a desired tfvars file name"
-  echo "create_tfvars_from_config.sh: <destination file path> <mlz config file path> <create bastion host> <create sentinel>"
+  echo "create_tfvars_from_config.sh: <destination file path> <mlz config file path> <create bastion host> <create sentinel> <create_assignment>"
   show_help
 }
 
@@ -30,6 +30,7 @@ file_to_create=$1
 mlz_config=$2
 create_bastion_jumpbox=${3:-true}
 create_sentinel=${4:-true}
+create_assignment=${5:-false}
 
 # source config
 . "${mlz_config}"
@@ -55,6 +56,7 @@ append_kvp "mlz_cloud" "${mlz_cloudname}"
 append_kvp "mlz_tenantid" "${mlz_tenantid}"
 append_kvp "mlz_location" "${mlz_config_location}"
 append_kvp "mlz_metadatahost" "${mlz_metadatahost}"
+append_kvp "create_assignment" "${create_assignment}"
 
 append_kvp "hub_subid" "${mlz_saca_subid}"
 append_kvp "hub_rgname" "rg-saca-${mlz_env_name}"