"NoOps is not about the elimination of ops; it is about the elimination of manual handoffs and low-value, rote administration." - Forrester

Azure NoOps Accelerator is a flexible foundation that enables US Department of Defense and other Public Sector customers to quickly develop and maintain opinionated, policy-driven, and self-service enclaves in their Azure environments.

Delivered as a collection of infrastructure as code (IaC) module templates written in Bicep, the NoOps Accelerator is intended to empower organizations on their journey towards a continuous deployment and governance model for their cloud infrastructure.

Learn more about the NoOps movement and philosophy here - What is NoOps?.

While the NoOps Accelerator can be used to build all sorts of useful solutions, a simple place to start is deploying a workload platform. You can use the NoOps Accelerator to deploy SCCA-compliant landing zones based on Microsoft's SACA implementation guidance and Mission Landing Zone architecture.

These steps walk through how to use NoOps to deploy a hub and spoke architecture. At the conclusion, you will have five resources groups mapped to the following:

• Hub: SCCA-compliant networking hub (1 vnet, 1 resource group)
• Tier 0 (T0): Identity & Authorization (1 vnet, 1 resource group)
• Tier 1 (T1): Infrastructure Operations, and Logging (1 vnet, 2 resource groups)
• Tier 2 (T2): DevSecOps & Shared Services (1 vnet, 1 resource group)

Steps:

1. Clone the repository down and change directory to the lz-platform-scca-hub-3spoke directory

   git clone https://github.com/Azure/NoOpsAccelerator.git
   cd NoOpsAccelerator/src/bicep/platforms/lz-platform-scca-hub-3spoke
   

2. Deploy the landing zone with the az deployment sub create command. For a quickstart, we suggest a test deployment into the current AZ CLI subscription using these parameters:

   • --name: (optional) The deployment name, which is visible in the Azure Portal under Subscription/Deployments.
   • --location: (required) The Azure region to store the deployment metadata.
   • --template-file: The file path to the deploy.bicep template.
   • --parameters: The file path to the parameters/deploy.parameters.json file, preceded by @. Individual parameters can be overwritten using <parameter>=<value> format as well.
   • --subscription: The GUID for the subscription to deploy into. Multiple subscriptions may be configured (i.e., to have separate subscriptions for each 'tier' in the MLZ architecture) in the parameters/deploy.parameters.json

   Here is an example that deploys into a single subscription in the EastUS region of Azure Commercial:

   # These will be used in the naming of your resources
   # e.g., anoa-eastus-dev-hub-rg
   ORG_PREFIX="anoa"
   DEPLOY_ENV="dev"
   
   # Replace with your test Azure Subscription ID
   AZ_SUBSCRIPTION="XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX"
   
   az login
   az deployment sub create \
       --name deploy-scca-hub-with-3-spokes \
       --location EastUS \
       --template-file deploy.bicep \
       --parameters @parameters/deploy.parameters.json \
       --parameters parRequired="{ \"orgPrefix\":\"$ORG_PREFIX\", \"templateVersion\":\"v1.0\", \"deployEnvironment\":\"$DEPLOY_ENV\" }" \
       --parameters parHubSubscriptionId=$AZ_SUBSCRIPTION \
       --parameters parIdentitySubscriptionId=$AZ_SUBSCRIPTION \
       --parameters parOperationsSubscriptionId=$AZ_SUBSCRIPTION \
       --parameters parSharedServicesSubscriptionId=$AZ_SUBSCRIPTION \
       --subscription $AZ_SUBSCRIPTION
   

3. After a successful deployment, see the enclaves folder for examples of complete, outcome-driven solutions built using the NoOps Accelerator. Also, be sure to take a look through our workloads and overlays folders to get a sense of the available pieces you can put together with the platform you just deployed to solve your mission challenges.

4. Don't forget to clean-up your environment by removing all of the resource groups created by the deployment when you are done with this Quickstart.

Don't have Azure CLI? Here's how to get started with Azure Cloud Shell in your browser: https://docs.microsoft.com/en-us/azure/cloud-shell/overview

• Design for US Government mission customers, with a specific focus on the US Department of Defense and Military Departments.
• Provide reusable and composable IaC modules that hyper-automate infrastructure deployment using Microsoft's best practices.
• Simplify compliance management through automated audit, reporting, and remediation.
• Deliver example Platform modules that implement SCCA controls and follow Microsoft's SACA implementation guidance.
• Support deployment to Azure Commercial, Azure Government, Azure Government Secret, and Azure Government Top Secret clouds.
• Accelerate the US Government's use of Azure by easing the onboarding of mission workloads, spanning mission applications, data, artificial intelligence, and machine learning.

• The NoOps Accelerator cannot automate the approval for Authority to Operate (ATO), though it will enable Customers to collect, customize, and submit for ATO based on their departmental requirements.
• The NoOps Accelerator will not strive for 100% compliance on all deployed Azure Policies for reference implementations. Customers must review Microsoft Defender for Cloud Regulatory Compliance dashboard and apply appropriate exemptions.

NoOps is amaze. Definitions of NoOps primitives.

Microsoft can identify the deployments of the Azure Resource Manager and Bicep templates with the deployed Azure resources. Microsoft can correlate these resources used to support the deployments. Microsoft collects this information to provide the best experiences with their products and to operate their business. The telemetry is collected through customer usage attribution. The data is collected and governed by Microsoft's privacy policies, located at https://www.microsoft.com/trustcenter.

If you don't wish to send usage data to Microsoft, you can set the customerUsageAttribution.enabled setting to false in global/telemetry.json.

Project Bicep collects telemetry in some scenarios as part of improving the product.

We have one.

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.opensource.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., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

Please see the Support and Feedback Guide. To report a security issue please see our security guidance.

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. 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.

This project is greatly influenced by and owes a debt of gratitude to the following:

• Common Azure Resource Modules Library
• Azure Landing Zones for Canadian Public Sector
• Mission Landing Zone