Enhancing Security with Gatekeeper | MuleSoft Documentation
# Enhancing Security with Gatekeeper
When you deploy an application, the tracked resources exposed by the application might become accessible for a short amount of time due to a lapse in security. Because the policies for those resources are not yet applied, the API might receive unwanted traffic. GateKeeper prevents this situation by blocking the tracked resource until all policies are retrieved and applied without errors.
Starting with CloudHub 4.2.2, Mule runtime engine (Mule) keep APIs blocked until the contracts of the API are successfully downloaded from the Management plane in case the policy requires contracts and if Gatekeeper is enabled. Gatekeeper waits until contracts are available to unblock the API.
In earlier versions of Mule, APIs were unblocked after the runtime successfully applied all the policies. For example, if the API had the Client ID Enforcement policy applied, a request with valid credentials was rejected.
This CloudHub update behaves the same way with `strict` and `flexible` Gatekeeper modes. Contracts are considered available if they are downloaded from the Contracts Service before or after Mule is restarted.
Out of the box policies that might require contracts include:
  * Client ID Enforcement Policy
  * Rate Limiting SLA Policy
  * JWT Validation Policy
  * PingFederate OAuth 2.0 Token Enforcement Policy
  * OpenID Connect OAuth 2.0 Token Enforcement Policy
  * Mule OAuth 2.0 Access Token Enforcement


## How Gatekeeper Works
The Gatekeeper mechanism is engaged only when you restart the runtime or redeploy a tracked resource that is linked with an API instance when automatically discovered. When Gatekeeper is engaged, each tracked resource is blocked, resulting in a `503 - Service Unavailable` HTTP status code, until all API instance policies are applied in API Manager without errors.
Resources not linked to an API instance when automatically discovered are ignored by Gatekeeper. Additionally, you cannot apply any policies to these resources, and no analytics information is generated. If you lose connectivity after the Mule instance is restarted or the tracked Mule application is redeployed, you use cached policies, configuration, and contracts, even if Gatekeeper is not enabled.
When Gatekeeper is engaged, if a tracked resource has a malformed or incorrectly defined policy applied, the tracked resource is blocked, resulting in a `503 - Service Unavailable` HTTP status code`. The resource reamains blocked until the offending policy is removed from API Manager. Mule runtime caches all policies and active contracts locally.
## Security Levels
To enable or disable Gatekeeper functionality, you can configure the following property with a specific security level:
```
anypoint.platform.gatekeeper
```

For example, to configure the `flexible` security level, you must specify the following property:
```
anypoint.platform.gatekeeper=flexible
```

  * Valid Values for Mule 4 Security Levels
    * `flexible`
    * `disabled`
  * Valid Values for Mule 3 Security Levels
    * `flexible`


For Mule runtime versions 4.8.0 or later. Gatekeeper blocks requests when editing the policy configurations. The Gatekeeper does not block requests when editing policy order. To disable Gatekeeper during editing, set the `anypoint.platform.gatekeeper` property to `false`:
```
anypoint.platform.gatekeeper.block_edit=false
```

### Security Level Definitions
You can apply `false`, `disabled`, `true`, `strict`, or `flexible` security levels to Gatekeeper, as explained in the following table:
**Security level** | **Description** | **Level in Mule 3.x** | **Level in Mule 4.x**  
---|---|---|---  
Gatekeeper does not apply any security, and the API might receive unwanted traffic before the policies are completely applied, without errors. | Available only for backward compatibility. | Replaced by `disabled`  
Gatekeeper does not apply any security. With this setting, the API might receive unwanted traffic during the period while the policies are being applied. | Unavailable | Available  
With this setting, the default security level is set to `Strict` | Available only for backward compatibility. Use `strict` or `flexible` instead. | Unavailable  
Gatekeeper security is set to its maximum level. When the Mule instance is restarted, the API is blocked with a `503` error until policies for each tracked resource are correctly applied. If connectivity to Anypoint Platform is lost when Gatekeeper is engaged, the tracked resource is blocked until the connection is reestablished. | Available | Available  
Gatekeeper security is set to intermediate level. When the Mule instance is restarted, the API is blocked with a `503` error. If the connectivity to Anypoint Platform is lost when Gatekeeper is engaged, local cache is used to apply the policies during the outage. If cache is unavailable, The tracked resource is blocked at least until the connection is reestablished. | Available in v3.8.6 or later, and v3.9.0 or later | Available in v4.1.0 or later  
### Default Gatekeeper Configuration
The following table illustrates a Gatekeeper configuration with default values:
**Runtime version** | **Default security level**  
---|---  
**3.8.6 and later on 3.8.x** | Flexible  
**3.9.1 and later on 3.9.x** | Flexible  
**4.1.0 and later** | Flexible  
## Troubleshooting Gatekeeper Issues in Mule v3.x
You might encounter issues with Gatekeeper with certain type of policies.
### Gatekeeper does not unblock the API when a resource-level policy is applied
In Mule 3.x, you can apply resource-level policies only to a RAML proxy or to an API implementation containing an APIkit router. Gatekeeper might repeatedly block an API when a resource-level policy is applied to it for one of the following reasons:
  * The expressions for URI and method selected when configuring the resource-level policy do not match any resource specified in the RAML definition.
To avoid this type of error, use the `Preview Resource Matching` option in API Manager when configuring the specific resource-level policy.
  * The autodiscovery element defined in the Mule application does not specify the `apikitRef` attribute.
To fix this issue, add the name of the APIkit configuration that the router is using to the `apikitRef` attribute.