Self-Managed Omni Gateway Security Best Practices
This page provides best practices to ensure your Omni Gateway runtime deployment meets industry standards.
Omni Gateway deployments consist of the runtime and control plane. Information such as configuration data and logging is shared between Anypoint Platform in the control plane and Omni Gateway in the runtime plane via mTLS communication. In the runtime layer, Omni Gateway orchestrates the incoming traffic and protects the upstream service or API. Omni Gateway is registered with Anypoint Platform by using a YAML registration file. Omni Gateway uses Redis shared storage to cache data to communicate with other Omni Replicas and cache request data. This diagram demonstrates an Omni Gateway deployment:
| Guidelines on this page are applicable to all Omni Gateway runtime environments, but diagrams are only provided for Kubernetes. |
Secure Omni Gateway in Anypoint Platform
Always apply the principle of least privilege to Omni Gateways in Anypoint Platform. Users who have access to Omni Gateway are able to view Omni Gateway configuration details and logs. Use users and team permissions to limit access to Omni Gateways to only those users who maintain the runtime. Provide read-only access except for users who deploy or manage the gateway configuration.
To learn how to manage access, see Access Management Overview.
Secure the Omni Gateway Registration Resource
Omni Gateway stores registration information locally. This registration resource contains the certificate the Omni Replica uses to communicate and authenticate itself with Anypoint Platform. Omni Gateway communicates with Anypoint Platform via mTLS.
Restrict access to the registration resource to ensure there’s no unauthorized execution of replicas. Specifically:
-
Ensure you encrypt secrets at rest and you enforce least privilege access for the registration resource secret.
-
Store sensitive data, such as credentials and API keys, in secure vaults, for example, AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault.
-
Avoid hardcoding secrets and only use environment variables for non-sensitive configurations.
-
Encrypt sensitive information in configuration files.
For best practices for Kubernetes deployments, see Good practices for Kubernetes Secrets.
Renew the Omni Certificate
Omni Gateway uses a managed PKI certificate to communicate with Anypoint Platform. This certificate is generated when you register Omni Gateway. Renew the certificate before its expiration date to ensure the runtime can connect to the control plane.
To learn how to renew your registration, see Renew Self-Managed Omni Gateway Registration.
Update your Omni Gateway
MuleSoft regularly provides security updates for Omni Gateway. Keep your Omni Gateway updated to the latest version to address vulnerabilities. To reduce the risk of incompatibilities, follow safe change processes and upgrade sandbox runtimes ahead of production.
To learn more about how to update your Omni Gateway, see Upgrade Self-Managed Omni Gateway.
Avoid Logging Payload Data
Runtime logs are available in the runtime layer through the stdout of the Omni Gateway pods and in the Anypoint control plane for Connected Mode.
To ensure compromised runtime logs don’t leak client information, avoid logging payload data in runtime logs.
If using other third party monitoring and analytics platforms, ensure you consider then in access reviews.
Secure Omni Gateway Service Pods
Restrict access to Omni Gateway runtime pods to ensure unauthorized personel cannot access Omni Gateway configuration data or tamper with the runtime.
For Kubernetes deployments, restrict access to command execution in the pod by using Kubernetes Role-based access control (RBAC). For more information, see Using RBAC Authorization.
In non-Kubernetes deployments, restrict access to the Omni Gateway virtual machine to open sessions.
Secure Redis Shared Storage
Omni Gateway uses Redis shared storage to cache request data and runtime configurations in Connected Mode only. An unauthorized user can obtain cached configuration data, such as Omni configuration or request processing caches, and can disrupt the runtime. You must secure the Redis service to prevent unauthorized access.
To secure the Redis shared storage, see Redis Recommended security practices. Enable access control to limit Redis access from sources other than Omni Gateway. Deploy the Redis as close as possible to the Omni Gateway deployment to further limit vulnerabilities.
Protect the Flow of Incoming Traffic (API Consumer to Omni Gateway)
How you protect the flow of incoming traffic from external attacks is dependent on the source of incoming traffic.
For requests coming from the public internet, configure a first line of defense system to intercept the traffic before it reaches the Omni Gateway. Omni Gateway provides API-level protection but relies on other general protections for the first line of defense. Ensure you have these protections:
-
Network level protections, like ACLs and DNS Firewalls. Cloud providers and third parties typically provide these protections.
-
First line application level protections, such as threat protection against DDoS attacks and Web Application Firewall.
| For guidelines on handling incoming requests from external sources, see Use Case 2: Organization-Owned API Exposed to a Non-Organization-Owned API Consumer and Use Case 4: Non-Organization-Owned API Exposed to a Non-Organization-Owned API Consumer. |
Terminate External TLS at Point of Entry
To enable the firewall to perform L7 traffic security inspections, terminate external TLS connections at the firewall level. A valid Certificate Authority (CA) that’s recognized by the consumer typically provides the certificates at this point of entry.
Use a separate set of certificates for internal communication between the firewall, Omni Gateway, and other services in the infrastructure. For this communication, use mTLS security with both certificates issued by an internal authority or PKI.
Certificates exposed to the internet are never used internally, and certificates that are used internally are never exposed to the internet. Separating internal and external certificates prevents potential leakage of the internal credentials.
You can use Omni Gateway at both the runtime environment ingress layer or at the inner environment layer. For Omni Gateways at the ingress layer, limit the gateways' scope to TLS termination, routing, and other basic protections. Push more CPU and memory intensive operations to inner Omni Gateways.
Protect APIs by Using Policies
Apply policies to enhance API protections. Omni Gateway offers Included Policies and enables you to develop custom policies by using Omni Gateway Policy Development Kit (PDK) Overview.
Govern APIs by Using API Governance
Use Anypoint API Governance to ensure you design and deploy APIs in line with MuleSoft, industry, and your organization’s best practices.
Protect the Upstream Service (Omni Gateway to API Provider)
How you protect the flow of traffic from Omni to the upstream service is dependent on the location of the upstream service.
Protect Services Available Locally to Omni Gateway
Services that share the same network as Omni Gateway typically have lower security restrictions.
The organization must define whether plain or TLS connections are in place. If using TLS, configure mTLS via Omni Gateway Outbound TLS contexts. To learn more about configuring TLS, see xref:
To protect the upstream service from other services in the same network, configure the upstream service to accept traffic only from Omni Gateway. For Kubernetes, configure this using Network Policies.
| For guidelines on communicating to an internal upstream service, see Use Case 1: Organization-Owned API Exposed to an Organization-Owned API Consumer and Use Case 3: Non-Organization-Owned API Exposed to an Organization-Owned API Consumer. |
Protect External Services
When protecting external services not in the same network, connect to the service using mTLS communication. Configure a trusted network link, such as private VPC, between the networks to enable Omni Gateway to securely access the upstream service without exposing the service to the public internet.
| For guidelines on communicating to an external upstream service, see Use Case 2: Organization-Owned API Exposed to a Non-Organization-Owned API Consumer and Use Case 4: Non-Organization-Owned API Exposed to a Non-Organization-Owned API Consumer. |
Perform Regular Testing
Perform regular penetration and vulnerability tests to identify new or regressed issues in your Omni Gateway deployment and exposed APIs. Consider these security aspects when testing:
-
User access controls in Anypoint Platform that enable access to Omni registration in Runtime Manager, logs in Anypoint Monitoring, and APIs in API Manager.
-
Access to the deployed Omni Gateway that affects its function or data.
-
Access to any configuration files used by the Omni runtime, especially the registration file.
-
Access to the Redis shared storage service.
-
Access to APIs deployed on the Omni Gateway.
-
Access to the upstream services protected by the Omni Gateway APIs.