NoOpsAccelerator/README.md

Azure NoOps Accelerator

"NoOps is a policy-based, automated process enabling organizations to deploy, monitor, and improve cloud operations.." - John Spinella, Creator of the Azure NoOps Accelerator

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 philosphy here - What is NoOps?.

Quickstart

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.

Deploy a SCCA-compliant Landing Zone (SCCA Hub with 3 Spokes) using the Azure CLI

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

Goals and Non-Goals of the Azure NoOps Accelerator Project

Goals

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

Non-Goals

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

Getting Started

NoOps is amaze. Definitions of NoOps primitives.

Architecture

Primitive	Definition
AzResources	Wrap Azure Resource Providers so that they understand how to fit and work together. The most basic building blocks in NoOps.
Overlays	Extend AzResources with specific configurations or combine them to create more useful objects. For example, one could use the kubernetesCluster overlay to deploy a Private AKS Cluster rather than using the Microsoft.ContainerService/managedClusters AzResource to deploy a vanilla AKS cluster. Similarly, one could create a virtualMachine overlay that combines the deployment of a Microsoft.Network/networkInterfaces with a Microsoft.Compute/virtualmachine since you will rarely if ever deploy a VM without an associated NIC.
Platforms	Combine Overlays and AzResources to lay the networking required to support mission workloads. NoOps is provided with two SCCA-compliant hub-and-spoke landing zone platforms. The Quickstart above walks through the deployment of a SCCA-compliant hub-and-3-spoke platform.
Workloads	Combine Overlays and AzResources to create solutions that achieve mission and operational goals. For example, one could mix a kubernetesCluster overlay (Private AKS Cluster) with a Microsoft.ContainerRegistry AzResource to create a Dev Environment Workload. Workloads can be deployed into either a new or an existing hub-peered virtual network.
Enclaves	Bring it all together -- combining a single Platform with one or more Workloads, and mixing in Zero Trust governance and RBAC -- to enable the rapid, repeatable, auditable, and authorizable deployment of outcome-driven infrastructure.

Telemetry

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.

Product Roadmap

We have one.

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.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 opencode@microsoft.com with any additional questions or comments.

Feedback, Support, and How to Contact Us

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

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

Special Thanks and Liner Notes

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