Infrastructure ¶

The infrastructure is configured as code via Terraform, for various reasons, and is deployed into a Microsoft Azure account provided by the California Department of Technology (CDT)’s Office of Enterprise Technology (OET) team.

The Azure portal is where you can view the infrastructure resources for DDRC. Azure DevOps is where our infrastructure pipeline is run to build and deploy those infrastructure resources.

Environments ¶

Within the CDT Digital CA directory, there are two Subscriptions, with Resource Groups under each. However, only one subscription is currently being used for DDRC.

Each of our environments corresponds to a single Resource Group and Terraform Workspace.

Environment	Subscription	Resource Group	Workspace
Dev	`CDT/ODI Production`	`RG-CDT-PUB-VIP-DDRC-D-001`	`dev`
Test	`CDT/ODI Production`	`RG-CDT-PUB-VIP-DDRC-T-001`	`test`
Prod	`CDT/ODI Production`	`RG-CDT-PUB-VIP-DDRC-P-001`	`default`

All resources in these Resource Groups should be reflected in Terraform in this repository. The exceptions are:

Secrets, such as values under Key Vault. prevent_destroy is used on these Resources.
Things managed by DevSecOps

Ownership ¶

The following things in Azure are managed by CDT’s OET DevSecOps team:

Subcriptions
Resource Groups
Networking
Front Door
- Web Application Firewall (WAF)
- Distributed denial-of-service (DDoS) protection
IAM
Service connections

You’ll see these referenced in Terraform as data sources, meaning they are managed outside of Terraform.

Architecture ¶

These diagrams show a high-level view of the architecture per environment, including some external systems such as error monitoring.

DDRC application ¶

flowchart LR
    internet[Public internet]
    frontdoor[Front Door]
    django[Django application]
    interconnections[Other system interconnections]

    internet --> Cloudflare
    Cloudflare --> frontdoor
    django <--> interconnections

    subgraph Azure
        frontdoor --> NGINX

        subgraph App Service
            subgraph Custom container
                direction TB
                NGINX --> django
            end
        end
    end

Front Door also includes the Web Application Firewall (WAF) and handles TLS termination. Front Door is managed by the DevSecOps team.

System interconnections ¶

flowchart LR
    ddrc[DDRC application]
    style ddrc stroke-width:5px
    rider((User's browser))
    idg[Identity Gateway]
    task_queue[Task queue]
    app_db[(PostgreSQL)]
    cookies[(Cookies)]
    monitoring[Azure Monitor]

    ddrc -->|Errors| monitoring

    rider --> ddrc
    rider -->|Credentials and identity proofing| Login.gov
    rider -->|Session| cookies

    ddrc --> idg
    ddrc <--> app_db

    subgraph "Database and task queue"
    task_queue <--> app_db
    end

    idg --> Login.gov
    Login.gov -->|User attributes| idg
    idg -->|User attributes| ddrc

Naming conventions ¶

The DevSecOps team sets the following naming convention for Resources:

 <<Resource Type>>-<<Department>>-<<Public/Private>>-<<Project Category>>-<<Project Name>>-<<Region>><<OS Type>>-<<Environment>>-<<Sequence Number>>

Sample Names ¶

RG-CDT-PUB-VIP-BNSCN-E-D-001
ASP-CDT-PUB-VIP-BNSCN-EL-P-001
AS-CDT-PUB-VIP-BNSCN-EL-D-001

Resource Types ¶

Use the following shorthand for conveying the Resource Type as part of the Resource Name:

Resource	Convention
App Service	`AS`
App Service Plan	`ASP`
Virtual Network	`VNET`
Resource Group	`RG`
Virtual Machine	`VM`
Database	`DB`
Subnet	`SNET`
Front Door	`FD`

Infrastructure pipeline ¶

When code is pushed to any branch on GitHub, our infrastructure pipeline in Azure DevOps runs terraform plan. When the pull request is merged into main, the pipeline runs terraform apply.

While other automation for this project is done through GitHub Actions, we use an Azure Pipeline for a couple of reasons:

Easier authentication with the Azure API using a service connnection
Log output is hidden, avoiding accidentally leaking secrets