DEVOPS PULL REQUEST

Related Issue

resolves #7560

Changes Proposed

Update azurerm provider version to 3.100.0
Update function app to use node version 20
ip_restriction_default_action and scm_ip_restriction_default_action are new attributes on app service.

Additional Information

Set ip_restriction_default_action to Deny, we don't want additional access to our app service or to bypass our load balancer, we want to utilize our ip_restriction settings.
Set scm_ip_restriction_default_action to Deny, we don't use Kudu/SCM site tools so we want to restrict any access to it.
Deployment steps
- Deploy to the environment using GH actions, it'll do most of the regular deployment work but it will fail because a resource already exists: Error: A resource with the ID "/subscriptions/***/resourceGroups/prime-simple-report-dev/providers/Microsoft.Web/sites/prime-simple-report-dev3-metabase/config/virtualNetwork" already exists - to be managed via Terraform this resource needs to be imported into the State.
- Log in to azcli
- run make init-<ENV>
- within the env directory for that environment run terraform import module.metabase_service.azurerm_app_service_virtual_network_swift_connection.metabase_vnet_integration /subscriptions/<SUBSCRIPTION>/resourceGroups/prime-simple-report-<RESOURCEGROUPNAME>/providers/Microsoft.Web/sites/prime-simple-report-<ENV>-metabase/config/virtualNetwork
- Rerun the deployment in GH actions, it should pass

Testing

Smoke test pentest and/or dev3 (pentest doesn't have metabase)
- Ensure the terraform plan for dev2, dev3, dev4, dev5, dev6, demo, training, stg, prod look acceptable
  - Ignore tag updates
  - Resources that should be updated in place
    - module.app_gateway.azurerm_application_gateway.load_balancer
    - module.metric_alerts.azurerm_monitor_metric_alert.cpu_util
    - module.metric_alerts.azurerm_monitor_metric_alert.mem_util
    - module.report_stream_reporting_functions.azurerm_linux_function_app.functions
    - module.simple_report_api.azurerm_linux_web_app.service
    - module.simple_report_api.azurerm_linux_web_app_slot.staging
  - Resources that shouldd be replaced
    - module.app_service_autoscale.azurerm_monitor_autoscale_setting.simplereport_autoscale
    - module.metabase_service.azurerm_app_service_virtual_network_swift_connection.metabase_vnet_integration
    - module.metabase_service.azurerm_key_vault_access_policy.app_secret_access
    - module.metabase_service.azurerm_linux_web_app.metabase
    - module.metabase_service.null_resource.service_plan_id
    - module.report_stream_reporting_functions.azurerm_storage_blob.appcode
- Ensure the function apps are working as intended
- Ensure the app service is only accessible through the gateway in our loadbalancer subnet

Checklist for Primary Reviewer

Infrastructure

[ ] Consult the results of the terraform-plan job inside the "Terraform Checks" workflow run for this PR. Confirm that there are no unexpected changes!

Security

[x] Changes with security implications have been approved by a security engineer (changes to authentication, encryption, handling of PII, etc.)
[x] Any dependencies introduced have been vetted and discussed

Cloud

[ ] Oncall has been notified if this change is going in after-hours
[ ] If there are changes that cannot be tested locally, this has been deployed to our Azure test, dev, or pentest environment for verification

Documentation

[ ] Any changes to the startup configuration have been documented in the README

Apr 23 '24 19:04 alismx

While reviewing the terraform-plan in github actions, I noticed there was a module named module.vnet.azurerm_subnet.db that has a status of updated in-place for the environment prod. This module was not annotated in the PR Testing section, is this module update intentional?

How do I complete the following test?
* Ensure the function apps are working as intended

* Ensure the app service is only accessible through the gateway in our loadbalancer subnet

@DanielSass Would you (or another dev) be willing to do a write up on how to smoke test the function apps?

@shanice-skylight As far as testing access to the app service:

go to the app service in Azure
click networking
Visit IP labeled Inbound Address, it should result in a 404.

Additionally, on the same networking page:

click the link for the Public network access which will take you to the Access Restrictions
Check that we only allow access from that environments load balancer.

Thanks for calling out the module.vnet.azurerm_subnet.db change, I'll look into that. :eyeglasses: That's not a change I noticed when deploying to other environments.

May 02 '24 19:05 alismx

While reviewing the terraform-plan in github actions, I noticed there was a module named module.vnet.azurerm_subnet.db that has a status of updated in-place for the environment prod. This module was not annotated in the PR Testing section, is this module update intentional? How do I complete the following test?
* Ensure the function apps are working as intended

* Ensure the app service is only accessible through the gateway in our loadbalancer subnet
@DanielSass Would you (or another dev) be willing to do a write up on how to smoke test the function apps?

@shanice-skylight As far as testing access to the app service:

go to the app service in Azure

click networking

Visit IP labeled Inbound Address, it should result in a 404.

Additionally, on the same networking page:

click the link for the Public network access which will take you to the Access Restrictions

Check that we only allow access from that environments load balancer.

Thanks for calling out the module.vnet.azurerm_subnet.db change, I'll look into that. 👓 That's not a change I noticed when deploying to other environments.

What I do to smoke test the function app is: ⚠️ Sharing steps for dev3 since that's where this is deployed 😸

First I open up the simplereportdev3app storage account "Queues"
- have fhir-data-publishing and test-event-publishing queues open
Go to https://dev3.simplereport.gov/app/queue and submit a single entry test with COVID and Flu result

Check both queues to see there is a message in the expected format/shape. (Example of a message from a test submission):

Smoke tested your changes on dev3 and the function app looks good to me!

May 03 '24 00:05 emyl3

While reviewing the terraform-plan in github actions, I noticed there was a module named module.vnet.azurerm_subnet.db that has a status of updated in-place for the environment prod. This module was not annotated in the PR Testing section, is this module update intentional?

How do I complete the following test?
* Ensure the function apps are working as intended

* Ensure the app service is only accessible through the gateway in our loadbalancer subnet

The part of the plan removing Microsoft.Storage from the subnet appears

While reviewing the terraform-plan in github actions, I noticed there was a module named module.vnet.azurerm_subnet.db that has a status of updated in-place for the environment prod. This module was not annotated in the PR Testing section, is this module update intentional? How do I complete the following test?
* Ensure the function apps are working as intended

* Ensure the app service is only accessible through the gateway in our loadbalancer subnet
@DanielSass Would you (or another dev) be willing to do a write up on how to smoke test the function apps?

@shanice-skylight As far as testing access to the app service:
1. go to the app service in Azure

2. click networking

3. Visit IP labeled `Inbound Address`, it should result in a 404.
Additionally, on the same networking page:
1. click the link for the `Public network access` which will take you to the  `Access Restrictions`

2. Check that we only allow access from that environments load balancer.
Thanks for calling out the module.vnet.azurerm_subnet.db change, I'll look into that. 👓 That's not a change I noticed when deploying to other environments.

@shanice-skylight It seems like the change to module.vnet.azurerm_subnet.db removing the Microsoft.Storage endpoint is no longer showing up in the plan. A little confusing but it seems like it's no longer a problem and we can move forward.

May 08 '24 19:05 alismx

@alismx I'm noticing the following being created: # module.metric_alerts.azurerm_monitor_metric_alert.uptime["prod-simplereport-gov-cdc-redirect"] will be created # module.metric_alerts.azurerm_monitor_metric_alert.uptime["prod-simplereport-gov-www-redirect"] will be created

and the following would be destroyed # module.metric_alerts.azurerm_monitor_metric_alert.uptime_redirects["prod-simplereport-gov-cdc-redirect"] will be destroyed # module.metric_alerts.azurerm_monitor_metric_alert.uptime_redirects["prod-simplereport-gov-www-redirect"] will be destroyed Is this just because this doesn't have the latest commits (particularly this one) from main that introduced these changes? 🤔

May 09 '24 20:05 emyl3

@alismx I'm noticing the following being created: # module.metric_alerts.azurerm_monitor_metric_alert.uptime["prod-simplereport-gov-cdc-redirect"] will be created # module.metric_alerts.azurerm_monitor_metric_alert.uptime["prod-simplereport-gov-www-redirect"] will be created

and the following would be destroyed # module.metric_alerts.azurerm_monitor_metric_alert.uptime_redirects["prod-simplereport-gov-cdc-redirect"] will be destroyed # module.metric_alerts.azurerm_monitor_metric_alert.uptime_redirects["prod-simplereport-gov-www-redirect"] will be destroyed Is this just because this doesn't have the latest commits (particularly this one) from main that introduced these changes? 🤔

Yup!

May 09 '24 20:05 alismx

if anyone's reading this in the future this wiki page was made as a testing reference