> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/azure/azure-web-app-access-restrict.md).

# Azure web app access restrict

Add an Access Restriction rule to one or more Azure App Service web apps for a configurable duration so you can test how clients behave when traffic to the web app is blocked.

Azure web app access restrict is an Azure chaos fault that adds an Access Restriction rule (`RULE_NAME`) to one or more App Service web apps listed in `AZURE_WEB_APP_NAMES` (in `RESOURCE_GROUP`, subscription `AZURE_SUBSCRIPTION_ID`) with `ACTION` against `IP_ADDRESS_BLOCK` at priority `PRIORITY` for `TOTAL_CHAOS_DURATION` seconds, then removes the rule. With the defaults (`Deny` against `0.0.0.0/0`), the web app rejects every inbound request from the front-end with `403 Forbidden` while the rule is in effect.

Use this fault to test how clients behave when traffic to an App Service web app is blocked without the app being stopped: whether Traffic Manager / Front Door reroute traffic, whether dependent services degrade gracefully, and whether monitoring detects the outage within the alerting SLA.

{% hint style="info" %}
**RUN YOUR FIRST EXPERIMENT**

If you have not configured the chaos infrastructure yet, go to [Quickstart](/resilience-testing/chaos-engineering/new-to-chaos-engineering/quickstart.md) to install the chaos infrastructure and run an experiment end to end.
{% endhint %}

***

### Use cases <a href="#use-cases" id="use-cases"></a>

Run this fault when you want to answer concrete questions like:

* **Web app blocked at the front-end:** When the Access Restriction returns 403 to every caller, do Traffic Manager / Front Door route around the web app inside the failover SLA?
* **Subset blocked:** Set `IP_ADDRESS_BLOCK` to a specific subnet to simulate blocking a single caller (for example, the API gateway).
* **Monitoring fidelity:** Do alerts on `Http4xx` or `Http403` fire inside the alerting SLA?
* **Recovery rehearsal:** Validate the runbook for removing an Access Restriction in case one is left over from a misconfiguration.

***

### Prerequisites <a href="#prerequisites" id="prerequisites"></a>

* **Kubernetes version:** 1.21 or later for the chaos infrastructure cluster.
* **Target web apps reachable:** Each entry in `AZURE_WEB_APP_NAMES` exists in `RESOURCE_GROUP`.
* **Azure credentials available:** Service principal File Secret, workload identity, or managed identity.
* **RBAC granted:** The principal includes the role listed below.

***

### Supported environments <a href="#supported-environments" id="supported-environments"></a>

| Platform                             | Support status                                              |
| ------------------------------------ | ----------------------------------------------------------- |
| App Service (Windows or Linux plans) | Supported                                                   |
| Function Apps                        | Supported (same `Microsoft.Web/sites/config` actions apply) |
| App Service Environment (ASE) v3     | Supported                                                   |

***

### Permissions required <a href="#permissions-required" id="permissions-required"></a>

The Azure principal used by the chaos pod needs the following role on the target resource group or subscription.

**Recommended built-in role:** `Website Contributor`

**Custom role (minimum actions):**

```json
{
  "Name": "Harness Chaos Web App Access Restrict",
  "Actions": [
    "Microsoft.Web/sites/read",
    "Microsoft.Web/sites/config/read",
    "Microsoft.Web/sites/config/write"
  ],
  "AssignableScopes": ["/subscriptions/<SUBSCRIPTION_ID>"]
}
```

Go to [Azure fault permissions](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/azure/security-configurations/fault-permissions.md) to read the full permission catalog.

***

### Authentication <a href="#authentication" id="authentication"></a>

Go to [Azure authentication methods](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/azure/security-configurations/azure-authentication-methods.md) to set up Service principal, Workload identity, or Managed identity.

***

### Fault tunables <a href="#fault-tunables" id="fault-tunables"></a>

Configure the following fault parameters when you add Azure web app access restrict to an experiment in Chaos Studio. Defaults are shown for reference.

**Required parameters**

| Tunable               | Description                                | Default    |
| --------------------- | ------------------------------------------ | ---------- |
| `AZURE_WEB_APP_NAMES` | Comma-separated list of web app names.     | (required) |
| `RESOURCE_GROUP`      | Resource group that contains the web apps. | (required) |

**Rule parameters**

| Tunable            | Description                                            | Default                 |
| ------------------ | ------------------------------------------------------ | ----------------------- |
| `RULE_NAME`        | Name of the Access Restriction rule the fault creates. | `chaos-experiment-rule` |
| `ACTION`           | Rule action: `Deny` (block) or `Allow` (whitelist).    | `Deny`                  |
| `PRIORITY`         | Priority of the rule (lower numbers take precedence).  | `300`                   |
| `IP_ADDRESS_BLOCK` | CIDR block that the rule applies to.                   | `0.0.0.0/0`             |

**Chaos parameters**

| Tunable                | Description                                                                                                                                                                                                      | Default |
| ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
| `TOTAL_CHAOS_DURATION` | Total duration of the fault in seconds. The rule stays in effect for this period.                                                                                                                                | `60`    |
| `CHAOS_INTERVAL`       | Delay in seconds between successive iterations when running for more than one cycle.                                                                                                                             | `60`    |
| `RAMP_TIME`            | Wait period in seconds before and after the fault. Go to [ramp time](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/common-tunables-for-all-faults.md#ramp-time) to read how it is applied. | `0`     |

**Authentication**

| Tunable                       | Description                                                                                           | Default |
| ----------------------------- | ----------------------------------------------------------------------------------------------------- | ------- |
| `AZURE_SUBSCRIPTION_ID`       | Target Azure subscription ID.                                                                         | `""`    |
| `AZURE_CLIENT_ID`             | Client ID of a user-assigned managed identity.                                                        | `""`    |
| `AZURE_AUTHENTICATION_SECRET` | Identifier of the **File Secret in Harness Secret Manager** that contains the service principal JSON. | `""`    |

Tunables that apply to every fault are documented in [common tunables for all faults](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/common-tunables-for-all-faults.md).

***

### Fault execution in brief <a href="#fault-execution-in-brief" id="fault-execution-in-brief"></a>

Updates the `ipSecurityRestrictions` of each web app in `AZURE_WEB_APP_NAMES` to add an entry named `RULE_NAME` with action `ACTION`, priority `PRIORITY`, applied to `IP_ADDRESS_BLOCK`. Waits for `TOTAL_CHAOS_DURATION`, then removes the rule and writes back the config.

***

### Expected behavior during fault execution <a href="#expected-behavior-during-fault-execution" id="expected-behavior-during-fault-execution"></a>

* The web app's front-end immediately enforces the new rule; matching traffic receives `403 Forbidden` (Deny) or non-matching traffic receives `403 Forbidden` (Allow with a narrow IP block).
* Existing connections may stay open briefly before the front-end recycles them.
* Azure Monitor shows a spike in `Http4xx` / `Http403` on the affected web apps.
* After the duration ends, the rule is removed and the web app accepts traffic normally again.

{% hint style="info" %}
**WHEN THE FAULT ENDS**

The chaos pod removes the rule from `ipSecurityRestrictions` and writes back the config. Front-end enforcement reverts within seconds.
{% endhint %}

#### Signals to watch <a href="#signals-to-watch" id="signals-to-watch"></a>

* **External availability:** Use an [HTTP probe](/resilience-testing/chaos-engineering/use-chaos-engineering/probes/http-probe.md) from a caller in the affected IP range and assert `403` during the chaos window.
* **Failover:** If Traffic Manager / Front Door is in front, use an HTTP probe on the public endpoint and assert it stays available.

***

### Verify the fault execution effect <a href="#verify-the-fault-execution-effect" id="verify-the-fault-execution-effect"></a>

1. **Inspect the Access Restrictions on the web app.**

   ```bash
   az webapp config access-restriction show \
     --resource-group <rg> \
     --name <webapp>
   ```

   You should see an entry named `RULE_NAME` during the chaos window and none after.
2. **Hit the web app URL from a caller in the blocked range.**

   ```bash
   curl -i https://<webapp>.azurewebsites.net
   ```

   Expect `403 Forbidden` during the chaos window.

***

### Recovery and cleanup <a href="#recovery-and-cleanup" id="recovery-and-cleanup"></a>

* **End of duration:** The chaos pod removes the `RULE_NAME` rule from each web app's `ipSecurityRestrictions`.
* **Abort the experiment:** Stopping the experiment from Chaos Studio also removes the rule.
* **Manual recovery:** Run `az webapp config access-restriction remove --resource-group <rg> --name <webapp> --rule-name <RULE_NAME>` for any web app that still has the rule.

***

### Limitations <a href="#limitations" id="limitations"></a>

* **Front-end enforcement:** Access Restrictions are enforced at the App Service front-end; in-region private endpoints may bypass them depending on configuration.
* **Same-subscription targeting:** A single experiment targets one `AZURE_SUBSCRIPTION_ID`.
* **Rule name collision:** If a rule named `RULE_NAME` already exists, the API call fails. Override `RULE_NAME` per experiment.
* **PRIORITY collisions:** If `PRIORITY` collides with an existing rule, the API call fails; pick an unused priority (300 is the default).

***

### Troubleshooting <a href="#troubleshooting" id="troubleshooting"></a>

<details>

<summary>Azure web app access restrict fails with rule already exists in Harness Chaos Engineering</summary>

A rule named RULE\_NAME (default chaos-experiment-rule) already exists on the web app. Remove it with az webapp config access-restriction remove -g -n --rule-name , or set RULE\_NAME to a unique value.

</details>

<details>

<summary>Azure web app access restrict fails with AuthorizationFailed</summary>

The Azure principal is missing Microsoft.Web/sites/config/write. Assign Website Contributor (or a custom role with the listed actions) on the target resource group or subscription.

</details>

<details>

<summary>Rule was not removed after the experiment ended</summary>

If the chaos pod exited before cleanup, run az webapp config access-restriction remove --resource-group --name --rule-name . Inspect the chaos pod logs to root-cause why cleanup failed.

</details>

***

### Related faults <a href="#related-faults" id="related-faults"></a>

* [Azure web app stop](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/azure/azure-web-app-stop.md): Stop the web app entirely instead of blocking traffic with a rule.
* [Azure instance stop](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/azure/azure-instance-stop.md): Stop a VM hosting the workload instead of an App Service web app.

{% @harness-feedback/feedback %}