Open Policies
An open policy is a provider-agnostic authoring experience. You configure one policy once, and MuleSoft translates it into each provider’s native policy and applies it across the instances you select, even a mix of Google Apigee, Azure API Management, Kong Gateway, and Omni instances at the same time. In the UI, open policies carry an Open badge, indicating that they work across all gateways.
You apply open policies from the Policy Library, which walks you through four steps: Select Policy, Configure Policy, Select Instances, and Review & Apply.
Open Use Cases
At launch, there are five open use cases. Each maps to a specific native policy per provider. See Supported Policies and Native Equivalents:
-
API Key Enforcement
-
CORS (Cross-Origin Resource Sharing)
-
Header Manipulation
-
IP Allowlist
-
JWT Validation
These are the primary policies you can create and edit across providers. Open policies also support several additional native Kong policies. See Supported Policies and Native Equivalents. Other recognized policies are view-only. See Policy Edit Restrictions.
Open Is a Creation Experience
Use an open policy to implement a use case across multiple native gateways from a single starting point. Only native policies remain on each provider. No separate open object exists, so you can’t edit or remove it.
After creation, the resulting native policies behave like any other native policy on each provider. From the Policies tab, you can edit, remove, enable, or disable them where the provider supports those actions. There is no open object to manage separately.
Confirming What Happened
Because open is only a creation experience, there is no dedicated open activity view. To see the outcome on each target, open that instance’s Activity log tab. Open applies appear there with the Open action type. See Tracking Policy Operations in the Activity Log.
|
When an open policy targets Omni instances, there is currently no Activity log record for those targets, so there’s no in-product way to confirm the outcome on Omni targets. This is a known limitation. For external providers (Apigee, Azure, and Kong), you can follow the outcome in each instance’s Activity log. |
Open Policies vs. Automated Policies vs. Controls
These three are easy to confuse. Use this comparison to choose the right tool:
| Open Policies | Automated Policies | Controls | |
|---|---|---|---|
What it is |
A create-only authoring experience: configure once, applied as each provider’s native policy across many instances, including external providers. |
Policies that auto-attach to any API matching a set of criteria (runtime, technology, environment, and so on), applied by rule, not to one hand-picked target. |
Reporting and compliance only: conformance reports for an API or instance. Doesn’t apply policies. |
Lifecycle |
None after creation. There’s no open object to edit or delete. |
Fully managed: create, edit, delete, and coverage changes as APIs come in and out of scope. |
Read-only reports. |
Scope |
Multi-provider, applied to the instances you select. |
Native to Omni and Mule, applied automatically by matching rules. |
Across APIs and instances. |
For automated policies and governance strategies, see Working with Governance Strategies.