--- schema_version: "1" id: 54ca846ca2e501e0c48f8f685c71ec33b1528248fe35c6acab27002cca6bb0af title: Self-Managed Flex Gateway Security Best Practices collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/gateway/1.12/flex-security-best-practices.md canonical_url: https://docs.mulesoft.com/gateway/1.12/flex-security-best-practices source_site: docs.mulesoft.com content_type: documentation content_hash: 0342b22c86584ba467f0ee858c62ca7ecef3c60bbafa590d75f36a06d0cdbeec description: MuleSoft Documentation Site release: "1.12" latest: false --- --- product: Omni Gateway version: 1.12 --- # Self-Managed Flex Gateway Security Best Practices > For the full documentation index, see: https://docs.mulesoft.com/llms.txt This page provides best practices to ensure your Flex Gateway runtime deployment meets industry standards. Flex 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 Flex Gateway in the runtime plane via mTLS communication. In the runtime layer, Flex Gateway orchestrates the incoming traffic and protects the upstream service or API. Flex Gateway is registered with Anypoint Platform by using a YAML registration file. Flex Gateway uses Redis shared storage to cache data to communicate with other Flex Replicas and cache request data. This diagram demonstrates a Flex Gateway deployment: ![security best practices](/mulesoft/current/en-us/gateway/1.12/_images/security-best-practices.png)
1Secure Flex Gateway in Anypoint Platform
2Protect your Flex Gateway:

  1. Secure Flex Gateway Service Pods

  2. Update your Flex Gateway

3Secure the Flex Gateway Registration Resource
4Renew the Flex Certificate
5Avoid Logging Payload Data
6Secure Redis Shared Storage
7Protect the Flow of Incoming Traffic (API Consumer to Flex Gateway)
8Protect the Upstream Service (Flex Gateway to API Provider):

  1. Protect Services Available Locally to Flex Gateway

  2. Protect External Services

9Perform Regular Testing
> [!NOTE] Guidelines on this page are applicable to all Flex Gateway runtime environments, but > diagrams are only provided for Kubernetes. ## Secure Flex Gateway in Anypoint Platform Always apply the principle of least privilege to Flex Gateways in Anypoint Platform. Users who have access to Flex Gateway are able to view Flex Gateway configuration details and logs. Use users and team permissions to limit access to Flex 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](https://docs.mulesoft.com/access-management/). ## Secure the Flex Gateway Registration Resource Flex Gateway stores registration information locally. This registration resource contains the certificate the Flex Replica uses to communicate and authenticate itself with Anypoint Platform. Flex 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](https://kubernetes.io/docs/concepts/security/secrets-good-practices/). ## Renew the Flex Certificate Anypoint Flex Gateway uses a managed PKI certificate to communicate with Anypoint Platform. This certificate is generated when you register Flex 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 Flex Gateway Registration](https://docs.mulesoft.com/gateway/1.12/flex-gateway-renew-certificate). ## Update your Flex Gateway MuleSoft regularly provides security updates for Flex Gateway. Keep your Flex 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 Flex Gateway, see [Upgrade Self-Managed Flex Gateway](https://docs.mulesoft.com/gateway/1.12/flex-gateway-upgrade). ## Avoid Logging Payload Data Runtime logs are available in the runtime layer through the `stdout` of the Flex 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 Flex Gateway Service Pods Restrict access to Flex Gateway runtime pods to ensure unauthorized personel cannot access Flex 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](https://kubernetes.io/docs/reference/access-authn-authz/rbac/). In non-Kubernetes deployments, restrict access to the Flex Gateway virtual machine to open sessions. ## Secure Redis Shared Storage Flex 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 Flex 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](https://redis.io/docs/latest/operate/rs/security/recommended-security-practices/). Enable access control to limit Redis access from sources other than Flex Gateway. Deploy the Redis as close as possible to the Flex Gateway deployment to further limit vulnerabilities. ## Protect the Flow of Incoming Traffic (API Consumer to Flex 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 Flex Gateway. Flex 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. > [!NOTE] For guidelines on handling incoming requests from external sources, see > [Use Case 2: Organization-Owned API Exposed to a Non-Organization-Owned API Consumer](https://docs.mulesoft.com/gateway/1.12/flex-architecture-uc2) > and > [Use Case 4: Non-Organization-Owned API Exposed to a Non-Organization-Owned API Consumer](https://docs.mulesoft.com/gateway/1.12/flex-architecture-uc4). ### 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, Flex 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 Flex Gateway at both the runtime environment ingress layer or at the inner environment layer. For Flex 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 Flex Gateways. ### Protect APIs by Using Policies Apply policies to enhance API protections. Flex Gateway offers [Included Policies](https://docs.mulesoft.com/gateway/1.12/policies-included-directory) and enables you to develop custom policies by using [Omni Gateway Policy Development Kit (PDK) Overview](https://docs.mulesoft.com/pdk/latest/policies-pdk-overview). ### Govern APIs by Using API Governance Use [Anypoint API Governance](https://docs.mulesoft.com/api-governance/) to ensure you design and deploy APIs in line with MuleSoft, industry, and your organization’s best practices. ## Protect the Upstream Service (Flex Gateway to API Provider) How you protect the flow of traffic from Flex to the upstream service is dependent on the location of the upstream service. ### Protect Services Available Locally to Flex Gateway Services that share the same network as Flex Gateway typically have lower security restrictions. The organization must define whether plain or TLS connections are in place. If using TLS, configure mTLS via Flex Gateway Outbound TLS contexts. To learn more about configuring TLS, see xref: - [Configuring TLS Context for Flex Gateway in Connected Mode](https://docs.mulesoft.com/gateway/1.12/flex-conn-tls-config) - [Configuring TLS Context for Flex Gateway in Local Mode](https://docs.mulesoft.com/gateway/1.12/flex-local-tls-config) To protect the upstream service from other services in the same network, configure the upstream service to accept traffic only from Flex Gateway. For Kubernetes, configure this using Network Policies. > [!NOTE] For guidelines on communicating to an internal upstream service, see > [Use Case 1: Organization-Owned API Exposed to an Organization-Owned API Consumer](https://docs.mulesoft.com/gateway/1.12/flex-architecture-uc1) > and > [Use Case 3: Non-Organization-Owned API Exposed to an Organization-Owned API Consumer](https://docs.mulesoft.com/gateway/1.12/flex-architecture-uc3). ### 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 Flex Gateway to securely access the upstream service without exposing the service to the public internet. > [!NOTE] For guidelines on communicating to an external upstream service, see > [Use Case 2: Organization-Owned API Exposed to a Non-Organization-Owned API Consumer](https://docs.mulesoft.com/gateway/1.12/flex-architecture-uc2) > and > [Use Case 4: Non-Organization-Owned API Exposed to a Non-Organization-Owned API Consumer](https://docs.mulesoft.com/gateway/1.12/flex-architecture-uc4). ## Perform Regular Testing Perform regular penetration and vulnerability tests to identify new or regressed issues in your Flex Gateway deployment and exposed APIs. Consider these security aspects when testing: - User access controls in Anypoint Platform that enable access to Flex registration in Runtime Manager, logs in Anypoint Monitoring, and APIs in API Manager. - Access to the deployed Flex Gateway that affects its function or data. - Access to any configuration files used by the Flex runtime, especially the registration file. - Access to the Redis shared storage service. - Access to APIs deployed on the Flex Gateway. - Access to the upstream services protected by the Flex Gateway APIs. ## See Also - [Integration Use Cases](https://docs.mulesoft.com/gateway/1.12/flex-architecture-uc-overview) - [Shared Storage Models](https://docs.mulesoft.com/gateway/1.12/flex-architecture-shared-storage)