Applying Automated Policies

Users with Organization Admin, Environment Admin, or with a role to Manage Policies in the environment can create, edit and delete Automated Policies.

Task Prerequisites

Before you apply an automated policy, ensure that:

  • Mule runtime engine (Mule) is installed with API gateway capabilities enabled.

  • An API configured with a basic endpoint or a proxy endpoint exists in API Manager.

  • A Mule application is deployed with a HTTP(s) based flow, which is linked to the API through Autodiscovery.

    When Autodiscovery is correctly configured in your Mule application, your applicationโ€™s API is said to be tracked by or paired to API Manager.

Autogenerated proxies handle these prerequisites in most cases. API gateway reconciles the automated policies applied to an API in API Manager during runtime.

Apply Automated Policy

To apply an automated policy:

  1. In API Manager, select Automated Policies from the left navigation menu.

  2. Click Apply new automated policy.

  3. Select the provided policy that you want to configure as a provided policy.
    You can configure any provided policies for Mule 4 as an automated policy.
    See the list of available Provided Policies to learn how to configure each one of them, or the Creating a Custom Policy article to learn how to create one.

    When configuring an automated policy, at the bottom of the policy configuration page, there is a Rule of Applications sub-section. This dictates the set of runtimes that will be affected by the policy:

    • Apply to all supported runtimes (4.1.1 and above).
      All API proxies based on Mule 4.1.1 and later will be affected by the policy.

    • Apply to a specific set of runtimes.
      You can configure a range of runtime versions to inherit the automated policy.
      For example, if the input From is 4.1.2 and the To value is 4.1.4, the automated policy will be applied to all deployed APIs inside this range. An API deployed on 4.1.5 wonโ€™t be affected by the policy.

      You can include values such as 4.1.x. For example, adding a range from 4.1.1 to 4.1.x covers all runtime patch releases. An API Proxy based on 4.1.0 will not be included in this range, because it’s lower than the 4.1.1 "from value."

      If you are configuring a type of policy that also exists as a provided policy in an API proxy affected by your rule of application, you’ll need to solve the conflict before continuing. Refer to the Conflict Management section below for more information on how to solve them.

  4. Click Apply

Itโ€™s recommended to apply an automated policy in a lower environment before applying in a production environment and ensure to review that an automated policy doesn’t affect the existing API contracts.

Conflict Management

Since automated policies have priority over API level policies, when adding an automated policy that it is already applied as an API Level policies, on API deployed using the selected runtime range, a conflict will be detected that needs to be solved before proceeding.

When a conflict is detected, a popup with the list of conflicting APIs will be displayed. A message will be shown with the first 10 APIs with conflicts and the total amount. You can use this endpoint to access the list of all APIs:

curl -X GET \
https://anypoint.mulesoft.com/xapi/v1/automated-policies/{groupId}/{assetId}/conflicting-apis \
-H 'Authorization: Bearer {token}'

To solve conflicts, you can either select the APIs from the list of already configured APIs and manually disable or remove the conflicting policy or choose to override all conflicting policies for the already configured APIs. If this last option is chosen the conflicting policies in the APIs will be disabled. If Automated Policy is removed, the API policy will be re-enabled automatically.

Deploying New APIs

When managing new APIs, you can see information regarding the status of the automated policies applied to your environment in the Policies tab. No automated policies are shown until the application is in Active status.
After the application is deployed, a list of applied automated policies will be listed in the Policies tab of the API.

Users with View Policies role for the environment will able to see the list of automated policies applied.
If an application is deployed to an environment which has an automated policy that doesn’t cover the deployed runtime, for example with an automated policy affecting a runtime range from 4.1.2 to 4.1.4, and a user deploys to a 4.1.5 runtime, a notification will be sent to the organization, and environment administrators, to let them know of this activity.

Auditing Applied Policies

It is possible to audit and get a list of all affected APIs by an automated policy. Reports can be filtered by runtime version, and by an operation.

To get the list of all automated policies in an environment

curl -X GET \
https://anypoint.mulesoft.com/apimanager/api/v1/organizations/{organizationId}/automated-policies?environmentId={envId} \
  -H 'Authorization: Bearer {token}'

To get the list of APIs included in the range of automated policy or APIs where the automated policy is not applied.

curl -X GET \
https://anypoint.mulesoft.com/apimanager/api/v1/organizations/{organizationId}/automated-policies/{automatedPolicyId}/apis \
-H 'Authorization: Bearer {token}'

Was this article helpful?

๐Ÿ’™ Thanks for your feedback!

Submit your feedback!
Share your thoughts to help us build the best documentation experience for you!
Take our latest survey!