Sentinel as code: greenfield CI/CD design

Chapter 1 explained Terraform. This chapter applies it to a whole Sentinel estate built from nothing: what can be code, what cannot, what to set up on day zero in Azure and in your DevOps platform, and a pipeline design you can defend in front of a security architect.

Two decisions that come before any code

1. The portal is no longer a choice.

• Sentinel in the Azure portal retires on 31 March 2027. After that it exists only in the Microsoft Defender portal.
• Since July 2025, a new customer's first workspace is onboarded to the Defender portal automatically, if the person onboarding is a subscription Owner or User Access Administrator and is not working through Azure Lighthouse delegation. Consultants often are delegated, so plan for the manual step.
• The Defender XDR connector is enabled automatically on Defender portal onboarding. Do not script it separately.
• Runbooks, RBAC design and analyst training should target the Defender portal, not the Azure blade.

2. Which tables go to which storage tier.

Analytics-tier data is mirrored to the lake at no extra charge. Sending data to the lake only has its own ingestion and processing meters. Since 23 September 2026, data lake onboarding is part of Sentinel onboarding, and you enable the lake tier per table in Table management. Write the tiering decision down per table, with an owner. It is the biggest lever on the bill, and the one most often decided by accident.

What is Terraform, what is ARM, what stays human

The greenfield build, in dependency order

Repository design

One repository, one folder per kind of content, one Terraform root, and a separate state file per environment. The branch and the pipeline stage decide the target environment. The repository does not.

rules/                 analytic rules, one YAML per detection
automation/            automation rules
watchlists/            CSV per watchlist + small YAML header
hunting/               hunting queries and parsers (KQL files)
workbooks/             workbook JSON
playbooks/             exported Logic App ARM templates
arm/                   Content Hub and codeless connector templates
terraform/
  providers.tf  variables.tf  outputs.tf
  platform.tf          workspace, onboarding, tables, RBAC
  content.tf           reads rules/, automation/, watchlists/, hunting/
  environments/dev.tfvars  environments/prod.tfvars
scripts/validate_rules.py  the quality gate, runs with no Azure access
azure-pipelines.yml   or  .github/workflows/
docs/runbook-human-steps.md   the consent steps, with owners

• State per environment: same storage account, different blob key: sentinel-dev.tfstate and sentinel-prod.tfstate. One environment's run can never touch the other's state.
• Platform and content can split later. When the content team and the platform team are different people, give each its own Terraform root and state so a rule change never plans against the workspace.
• Rule identity is the GUID, not the file name or display name. Never reuse or change one.

Identities and roles

Least privilege means scoping each identity to the smallest thing that works:

Day-zero setup, first time ever

The order matters. Azure comes first because the DevOps platform needs something to connect to.

Step 1: Azure foundation (once, by a subscription Owner, in Cloud Shell or the CLI)

• Create the resource group and the Log Analytics workspace, and enable Sentinel on it.
• Create the state storage account: Entra-only access, public blob access off, versioning on, and a tfstate container.
• Onboard the workspace to the Defender portal, if that did not happen automatically.

This is the one part that cannot itself be in the pipeline, because the pipeline needs the state storage and its identity to exist before it can run. Keep it in a reviewed bootstrap script in the repository.

Step 2: the DevOps platform. Pick one.

The pipeline design

The pipeline file

trigger:
  branches: { include: [main] }
  paths: { include: [rules/*, terraform/*] }

variables:
  serviceConnection: sc-sentinel-oidc    # the service connection's name

stages:
  - stage: validate
    jobs:
      - job: validate
        pool: { vmImage: ubuntu-latest }
        steps:
          - script: |
              pip install -r requirements-dev.txt
              python scripts/validate_rules.py --strict
              pytest -q
            displayName: Validate rules (no Azure access)

  # ... plan and deploy_dev stages follow the same shape ...

  - stage: deploy_prod
    dependsOn: deploy_dev
    condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
    variables:
      - group: sentinel-prod
    jobs:
      - deployment: apply
        environment: sentinel-prod       # the Approvals check lives here
        pool: { vmImage: ubuntu-latest }
        strategy:
          runOnce:
            deploy:
              steps:
                - checkout: self         # deployment jobs do not check out by default
                - script: |
                    curl -sSLo tf.zip https://releases.hashicorp.com/terraform/1.9.8/terraform_1.9.8_linux_amd64.zip
                    unzip -o tf.zip -d "$(Agent.ToolsDirectory)/tf"
                    echo "##vso[task.prependpath]$(Agent.ToolsDirectory)/tf"
                  displayName: Install pinned Terraform
                - task: AzureCLI@2
                  displayName: terraform apply
                  inputs:
                    azureSubscription: ${{ variables.serviceConnection }}
                    scriptType: bash
                    scriptLocation: inlineScript
                    workingDirectory: terraform
                    inlineScript: |
                      terraform init -input=false \
                        -backend-config="resource_group_name=$(TFSTATE_RESOURCE_GROUP)" \
                        -backend-config="storage_account_name=$(TFSTATE_STORAGE_ACCOUNT)" \
                        -backend-config="container_name=tfstate" \
                        -backend-config="key=sentinel-prod.tfstate" \
                        -backend-config="use_oidc=true" \
                        -backend-config="use_azuread_auth=true"
                      terraform apply -input=false -auto-approve \
                        -var-file=environments/prod.tfvars
                  env:
                    ARM_USE_OIDC: true
                    ARM_CLIENT_ID: $(AZURE_CLIENT_ID)
                    ARM_TENANT_ID: $(AZURE_TENANT_ID)
                    ARM_SUBSCRIPTION_ID: $(AZURE_SUBSCRIPTION_ID)
                    ARM_ADO_PIPELINE_SERVICE_CONNECTION_ID: $(SERVICE_CONNECTION_ID)
                    SYSTEM_ACCESSTOKEN: $(System.AccessToken)
                    SYSTEM_OIDCREQUESTURI: $(System.OidcRequestUri)
                    TF_VAR_log_analytics_workspace_id: $(LOG_ANALYTICS_WORKSPACE_ID)

Three ways to do Sentinel CI/CD

The defensible answer in a design review is a hybrid: Terraform for the platform and content lifecycle, ARM for the gaps (deployed from the same pipeline), and a written runbook for the consent steps. To build all of this yourself, part 3 is a hands-on lab.

Traps that cost a day each

What to automate next, in order

• Analytic rules: the highest change rate and the clearest review value. Start here.
• Automation rules and watchlists: small, stable, and rules depend on them.
• Hunting queries and parsers: saved searches, same pattern.
• Workbooks: JSON in the repository, one resource each.
• Playbooks: exported ARM templates, plus the connection runbook step.
• Content Hub solutions: ARM from the solution package, deployed by the same pipeline.
• Tables, retention and DCRs: once the tiering decision is written down.

Test yourself

Sources

Checked 25 October 2026. Re-check retirement dates and onboarding behaviour before quoting them to a client: the Azure portal retirement has already moved once.

• Sentinel in the Azure portal: retirement timeline
• Microsoft Sentinel in the Defender portal
• Manage data tiers and retention
• Manage content as code with Sentinel repositories
• Azure DevOps: create an organization and free tier of parallel jobs
• Azure DevOps: workload identity service connections
• azurerm provider: authenticating with OIDC and the azurerm backend