Description
Removing the terraform providers from the source repo. Add downloading of the providers to the development container build (and any possible future container definition) so that building the container will result in the providers being in the expected location.

Acceptance Criteria

• Terraform providers are no longer assets in the git repo
• The development container definition is updated to download the providers to the correct location during container builds
• If there is a customer container (depending on the timing of this issue), it packages the providers in the same way the development container does it
• Users who do not use one of our container definitions have instructions on how to get and where to put the providers.

Description
In order to bridge the gap between the UI to terraform, scripts need to be written to ingest and output the required templates for various sections inside of a config file.

Acceptance Criteria

• Script reads the config file and writes out the required files
• Script only writes out the sections specified during execution (I.E. if only making changes to Tier 3 and executing Tier 3 these are the only items processed)

Description
Create a CONTRIBUTING.md document with instructions on contributing to this project.

Acceptance Criteria

• The document has the guidance below, at a minimum:

# Contributing

This project welcomes contributions and suggestions. Most contributions require you to
agree to a Contributor License Agreement (CLA) declaring that you have the right to,
and actually do, grant us the rights to use your contribution. For details, visit
https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need
to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the
instructions provided by the bot. You will only need to do this once across all repositories using our CLA.

This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/).
For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/)
or contact [[email protected]](mailto:[email protected]) with any additional questions or comments.

Description

There should be an action triggered by Pull Requests that validate and lint Terraform code so that all modules are able to be initialized without issue and share a common format.

Acceptance Criteria

• Some workflow is triggered on Pull Request
• The workflow runs terraform validate and terraform fmt -check on all .tf in the repository
• The workflow fails the run if validation errors or formatting errors are present

What happens:

When invoking a Mission LZ script with a dependency on Azure CLI, I can do so from a terminal where my access has expired, but, Mission LZ scripts will continue to execute as if nothing is wrong and could put me into a weird state/confuse a user:

You'll notice mission LZ scripts continuing to try and execute Service Principal does not exist...creating despite not being able to get out and query that information to begin with.

Example:

> scripts/mlz_tf_setup.sh gmusadev eastus public
Verifying Service Principal is unique (sp-tf-mlz-gmusadev)
ERROR: AADSTS70043: The refresh token has expired or is invalid due to sign-in frequency checks by conditional access. The token was issued on 2021-02-17T15:42:34.0134674Z and the maximum allowed lifetime for this request is 43200.
Trace ID: [redacted]
Correlation ID: [redacted]
Timestamp: 2021-02-22 21:30:24Z
Service Principal does not exist...creating
ERROR: AADSTS70043: The refresh token has expired or is invalid due to sign-in frequency checks by conditional access. The token was issued on 2021-02-17T15:42:34.0134674Z and the maximum allowed lifetime for this request is 43200.
Trace ID: [redacted]
Correlation ID: [redacted]
Timestamp: 2021-02-22 21:30:25Z

What I expect to happen:
The script should fail gracefully and tell me to run az login

Description
Tier 0 has a subnet for Privileged Access Workstations (PAWs)

Acceptance Criteria

• The T0 PAW subnet is deployed using Terraform templates

Description
Each tier/sub has a unique Log Analytics workspace

Acceptance Criteria

• Each tier/sub has a unique Log Analytics workspace deployed using Terraform

Description
Remove the word "template" from the Issue template.

Acceptance Criteria

• New Issue shows "Issue" instead of "Issue template"

automation that tears down all mlz-config resources (config RG, deletes service principal, removes service principal from sub RBAC, deletes and purges KV)

Description

Acceptance Criteria

• Complete set of source code exists

Description
High availability for PAWs in all T0-T2. Failover is potentially in scope,. Requires analysis on the appropriate level of HA.

Acceptance Criteria

• HA availability level is defined and added to the documentation.
• Testing proves availability and failover promises.

Description

We could use a nightly build to know if any changes in source have occurred that would effect the ability to deploy missionlz.

The assumption is that if this build is broken, the product is in an non-working state and the team swarms to resolve the problem as quickly as feasible.

Will look to where this can be done from internal tooling.

This may depend on finishing #89.

Acceptance Criteria

• Assumes mlz_tf_setup has been run for the pipeline
• The build uses some configurable subscription ID(s) to deploy into
• The build uses the same container developers use
• The build runs terraform apply for the base Hub + Spoke
• The build runs terraform destroy for the base Hub + Spoke
• The build runs the Bicep deployment with defaults

Description

Currently, I set the enclave name and location from the command line. Instead, let's source this from the common configuration file so that the UI can dump this information for us too.

Acceptance Criteria

• Rename enclave to mlz_env_name
• Provide mlz_config_location as a means to specifying configuration resource locations

Description
Tier 2 has a subnet for Privileged Access Workstations (PAWs)

Acceptance Criteria

• The T2 PAW subnet is deployed using Terraform templates

Description
Create a subnet in T2 for DevSecOps

Acceptance Criteria

• A subnet for DevSecOps is deployed to T2 with Terraform

Description
Review and update the README.md document in preparation for public consumption.

Acceptance Criteria

• Include product roadmap information
• Incorporate Getting Started information - probably a link to another markdown document
• Include the required text below

Trademarks This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow [Microsoft's Trademark & Brand Guidelines](https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/usage/general). Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party's policies.

Description
Need to choose the technology for remote access and agree on a high level design.

Acceptance Criteria

• Decisions are documented in a set of GH issues that describe what will be implemented for remote access
• Understand the intent of remote access as it relates to each tier

Description
Tests that prove the deployed landing zone functions as expected. The goal of this issue is to demonstrate how the functional tests would be written. Future tests are the scope of future features, or may be done as a single effort. Desired outcome is to understand how the tests will be written so that we can estimate the cost.

The intent of tests is to validate:

• Networking configurations
• The existence of provisioned resources
• The proper functioning of any custom code, e.g. the user interface or custom APIs

Tests can be written in the simplest technology possible, e.g. Azure CLI, Azure functions, containers, Azure Policy, etc.

Acceptance Criteria

• At least one networking test.
• The test returns either a positive result or a failure

Description
The UI must write out a configuration file before executing the underlying template modules. The output will be Python ConFig Parser read/writable

Acceptance Criteria

• UI Outputs a Config File Prior to Executing Terraform

Description
Add documentation on security reporting.

Acceptance Criteria

• Guidance is visible. Sample template is below:

## Security

Microsoft takes the security of our software products and services seriously, which includes all source code repositories managed through our GitHub organizations, which include [Microsoft](https://github.com/Microsoft), [Azure](https://github.com/Azure), [DotNet](https://github.com/dotnet), [AspNet](https://github.com/aspnet), [Xamarin](https://github.com/xamarin), and [our GitHub organizations](https://opensource.microsoft.com/).

If you believe you have found a security vulnerability in any Microsoft-owned repository that meets Microsoft's [Microsoft's definition of a security vulnerability](https://docs.microsoft.com/en-us/previous-versions/tn-archive/cc751383(v=technet.10)), please report it to us as described below.

## Reporting Security Issues

**Please do not report security vulnerabilities through public GitHub issues.**

Instead, please report them to the Microsoft Security Response Center (MSRC) at [https://msrc.microsoft.com/create-report](https://msrc.microsoft.com/create-report).

If you prefer to submit without logging in, send email to [[email protected]](mailto:[email protected]).  If possible, encrypt your message with our PGP key; please download it from the the [Microsoft Security Response Center PGP Key page](https://www.microsoft.com/en-us/msrc/pgp-key-msrc).

You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Additional information can be found at [microsoft.com/msrc](https://www.microsoft.com/msrc).

Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue:

  * Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.)
  * Full paths of source file(s) related to the manifestation of the issue
  * The location of the affected source code (tag/branch/commit or direct URL)
  * Any special configuration required to reproduce the issue
  * Step-by-step instructions to reproduce the issue
  * Proof-of-concept or exploit code (if possible)
  * Impact of the issue, including how an attacker might exploit the issue

This information will help us triage your report more quickly.

If you are reporting for a bug bounty, more complete reports can contribute to a higher bounty award. Please visit our [Microsoft Bug Bounty Program](https://microsoft.com/msrc/bounty) page for more details about our active programs.

## Preferred Languages

We prefer all communications to be in English.

## Policy

Microsoft follows the principle of [Coordinated Vulnerability Disclosure](https://www.microsoft.com/en-us/msrc/cvd).

Description
Document the steps required for an end-user to add their subscriptions to a Management Group or create their own.

Acceptance Criteria

• The deployment creates a management group.
• The management group is created with defaults.
• Subscriptions in the deployment are added to the management group.
• Document the approach for Management Groups and why they may or may not be a fit next to a Mission LZ deployment

Description

The only way to get names out of the MissionLZ initial setup is to capture them when they're initially created. We need to know their names so that we can access configuration at CI/CD time

Acceptance Criteria

• Any config.vars file can be derived given a MissionLZ configuration file and a Terraform configuration directory
• Any Mission LZ configuration resource name can be derived given a MissionLZ configuration file

Create templates for bug, feature request, and issue.

Customer reported error because the T0 SP does not have permissions to edit the saca hub. Resolved by granting the SP contributor access to saca hub.

Description

Need to be able to apply and destroy all the terraform in the repo given a MLZ configuration on demand. This will enable us to build a pipeline that could be run on some schedule or on certain PRs to ensure a working solution.

Acceptance Criteria

• Using well known .tfvars, apply all terraform configuration at src/core
• Using well known .tfvars, destroy all terraform configuration at src/core
• Enable -auto-approve for terraform commands for unattended invocation

Description
The UI shouldn't be a static template that needs to be modified directly every time a new configurable entity is added to the set of templates. The UI should comb the directories and find front end configuration templates and generate the forms for each of the individual tiers.

Acceptance Criteria

• Each Tier Has a json template specifying UI components and sub modules
• Each module has json template specifying UI components for configuration
• System automatically reads all of these and generates a front end view with default values for a user to execute MLZ from

"preflight" validation in the shell (storage account/keyvault/service princial uniqueness, resource names containing illegal chars) using the API documented REGEX

Description
We don't log network flow of NSGs.

Per the docs: "Flow logs are the source of truth for all network activity in your cloud environment. Whether you're an upcoming startup trying to optimize resources or large enterprise trying to detect intrusion, Flow logs are your best bet. You can use it for optimizing network flows, monitoring throughput, verifying compliance, detecting intrusions and more."

Network Security Group Flow Event docs: https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-nsg-flow-logging-overview

Expected behavior
NSGs have network flow logged

Actual behavior
NSGs do not have network flow logged

Description
All source files created by Microsoft employees are required to have a copyright header as a comment with the two lines shown below.

# Copyright (c) Microsoft Corporation.
# Licensed under the MIT License.

Note: third party contributors can add their own copyright header so long as they keep all pre-existing copyright notices intact in the files they are contributing. So contributors can add their own copyright header to their original contributions, as well as to files they modify and contribute back to the Microsoft OSS project. Microsoft should not add a Microsoft copyright header to third party contributions to Microsoft OSS projects. We should never remove copyright notices from files.

We should only add Microsoft copyright headers to files coded by Microsoft employees. If Microsoft employees modify third party code they may (but are not required to) add a Microsoft copyright header to the file so long as we keep intact all pre-existing copyright notices in the file.

Acceptance Criteria

• All files have the two lines of copyright code text above as a comment.

Benefit/Result/Outcome
A single tier is deployed and networked so that a workload can be hosted there.

Description
This issue describes the core setup of tier 3 - workloads. A Tier 3 is a container for one or more workloads within a vnet and related configuration and logging configuration.
Every deployment is additive - new vnets are created each time. Multiple T3 vnets can exist in the same subscription.
Peering among workloads is done via the hub.

The user interface is not include in the scope of this issue. It included in issue #168

Acceptance Criteria

• A separate deployment is available that sets up a tier 3, i.e. a separate script.
• All tier 3s include a VNet configured with peering.
• Logging is configured.
• Multiple T3s can be deployed into a single MLZ environment.
• Guidance/instructions/documentation on T3s and deployment is available, including modifying the main README to describe what a tier 3 is and how it is used.

Is your feature request related to a problem? Please describe.
It's frustrating when things go wrong. It's even more frustrating if I don't have a way to know what went wrong. If something goes wrong (or right) with any of the automation in missionlz today the only way to know what had happened is if I access stdout.

Describe the solution you'd like

• I'd like for missionlz to have the capability to log what's happening in a file I can access on disk.
• It should probably be gitignored for my own safety.

Describe alternatives you've considered
I guess I could expand my terminal history, or write out to App Insights in a RESTful way...but those seem complicated.

Additional context
Might be helpful for debugging issues as they're reported. Folks don't have enough information to answer what's wrong? Maybe a log file would help.

Description

GitHub Actions workflows should use the same Dockerimage that is used for configuring a developer's local environment.

This can be achieved with the jobs.<job id>.container workflow steps: https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idcontainer

For now the team could host the image in a private registry, but it should be investigated if there's value in publishing directly to Docker Hub or some other public registry.

Acceptance Criteria

• Where necessary, workflows make use of the container image from the team's private container registry
• A new Service Principal is created with solely "acrpull" scope on solely the private registry resource
• The Service Principal client ID and client secret are stored as encrypted secrets in GitHub
• The Service Principal credentials are stored in some KeyVault with appropriate RBAC permissions

Description
Create a subnet and NSG in T2 for resources that need private endpoints.

Acceptance Criteria

• A subnet and NSG are deployed via Terraform that are configured for private endpoints.

Description
Define which parts of SCCA are implemented

Acceptance Criteria

• Mapping document is available in the code repository

Description
Tier 1 has a subnet for Privileged Access Workstations (PAWs)

Acceptance Criteria

• The T1 PAW subnet is deployed using Terraform templates

Description

Log Analytics Workspace names must be globally unique

Acceptance Criteria

• Use the random provider when creating the log analytics workspace in the hub module

Description
The MLZ Configuration UI requires a login to verify at a minimum that the user is within the tenant that the MLZ templates are being deployed from.

Acceptance Criteria
When accessing the UI it requires a user to login.
UI backend interfaces with AAD to login and verify the user and obtain a token
The UI rest end points requires a valid session in order to perform any functions

Description
Add sections for persona and business justification/benefit to the Issue template, at the same level as Description.

Acceptance Criteria

• Persona is part of the template
• Business justification/benefit is part of the template

Description
A CI/CD deployment is needed to validate that the Terraform templates work in the commercial cloud.

Acceptance Criteria

• A set of actions exists that will deploy the solution to the commercial cloud.
• Secrets are not stored in GitHub
• Notifications are available when the deployment breaks, i.e. when Terraform has an error deploying
• Functional tests are out of scope

Description
Need diagrams that describe what's being built for March, from a customer point of view. Ideally the diagrams will be something friendly to markdown.

Acceptance Criteria

• One or more diagrams that describes the elements being released in March.
• The diagram(s) show the relationships among the elements.

Description

A nightly deployment that validates that the Bicep and Terraform templates work in the public and government clouds.

Acceptance Criteria

• A set of actions exists that will deploy the solution to the commercial and government clouds.
• Secrets are not stored in GitHub
• Functional tests are out of scope
• run az deployment create of Bicep on main (will be done in AzDevOps)
• run terraform apply of Terraform on main (will be done in AzDevOps)
• Notifications are available when the deployment breaks
• A pipeline success/fail badge on the root README

Description
The UI has to execute a series of changes in Azure in order to deploy configuration and register user login. These scripts must be run prior to the UI becoming accessible to a user. Pre-deployment scripts must provide both an option for providing artifacts to be transferred to an airgapped environment as well as deploy locally.

Acceptance Criteria

• Deployment scripts create the entire suite of Azure services needed for the UI
• Preparation scripts create a reasonably sized compressed file package that can be easily moved.