Application Security

Security Features Overview

Ingress gateways act as the entry point to Service Mesh. All incoming traffic can be encrypted using Transport Layer Security (TLS) or Mutual TLS (mTLS). OCI Certificate Service can automatically supply your certificates to your mesh or you can bring your own. You can also specify host names, ports, and protocols for your incoming traffic. Ingress gateway route tables route traffic to the appropriate virtual service based on protocol or the path of the request.

For more information, see: Creating an Ingress Gateway Route Table

Service Mesh includes mTLS support for mesh, ingress gateway, and virtual service components. mTLS is a method for mutual authentication between components. mTLS verifies parties at each end of a network connection by ensuring both parties have the correct private key. When OCI Certificate Service is used with Service Mesh, Certificate Authorities (CA) can be configured to automatically manage the certificates used for authentication and encryption between Service Mesh resources.

Service Mesh includes an Access Policy feature. Access policies determine communication routes from virtual service to virtual service, or from a virtual service to an external service.

For more information about security, see: Oracle Security, Identity, and Compliance

Using mTLS with Service Mesh 🔗

Service Mesh supports Mutual TLS (mTLS) for mesh and virtual service components. mTLS is a method for mutual authentication between components. mTLS verifies parties at each end of a network connection by ensuring both parties have the correct private key. This feature is implemented in Service Mesh with the following values when selecting an mTLS mode.

• Disabled: Raw TCP traffic is accepted. Communication is unencrypted.
• Permissive: Both mTLS and raw TCP traffic is accepted. Communication in the mesh is mTLS encrypted. Communication from outside the mesh is allowed to be unencrypted.
• Strict <default>: Only mTLS encrypted traffic is accepted.

You can set mTLS at the mesh and the virtual service level. So how do the different settings interact?

To set the mTLS settings in the user interface see:

• for a mesh: Create a Mesh.
• for a virtual service: Creating a Virtual Service.

Understanding Mesh and Virtual Service mTLS Interactions

When a minimum mTLS mode is specified on a mesh, the setting is enforced for all communication within the mesh. Mesh communications include ingress gateway to virtual service and virtual service to virtual service. A virtual service must set an mTLS mode to change the default setting. If the mTLS mode configuration is skipped on virtual services, then for the virtual services in that mesh the mTLS mode defaults to the mesh setting.

If the mTLS mode is set on the virtual service, the setting must be at least as restrictive as the minimum mode on mesh. Otherwise, the create or update operation is rejected. So in other words, the minimum mTLS mode set at the mesh governs what values are allowed for the mTLS mode on virtual services. For example, if the minimum mTLS mode on the mesh is STRICT then only STRICT is allowed for mTLS on virtual services. If the minimum mTLS mode on the mesh is PERMISSIVE, then virtual services can be PERMISSIVE or STRICT. In addition, there can be a mix of virtual services some at PERMISSIVE, some at STRICT.

An Ingress gateway is used for communication from outside the mesh. The minimum mTLS mode does not affect the communication coming from outside the mesh to the ingress gateway. The mTLS mode only affects the communication between the ingress gateway and virtual services.

For more information on setting the ingress gateway TLS mode, see Creating an Ingress Gateway.

Handling Incoming Traffic to a Virtual Service

For any virtual service, incoming traffic comes from three sources:

1. Traffic from a virtual service is considered within a mesh traffic.
2. Traffic from an ingress gateway is considered within a mesh traffic.
3. Traffic from any other application or service which is not meshified is considered traffic from outside the mesh.

Based on the incoming traffic type and the mTLS setting, the following describes how the virtual service handles the communication.

• If the mTLS is set to DISABLED, all communication in the three preceding scenarios is unencrypted.
• If the mTLS mode is set to PERMISSIVE, all communication within the mesh (1) and (2) is encrypted using mTLS. Communication from outside the mesh is allowed and might be unencrypted assuming the service does not have TLS.
• If the mTLS mode is set to STRICT, all communication within the mesh (1) and (2) is encrypted using mTLS. Communication from outside the mesh is not allowed.

Managing mTLS Certificates using Certificate Service 🔗

An Oracle Certificate Service certificate authority is used with Service Mesh to automatically manage your mTLS certificates. By default, certificates have a maximum validity of 45 days and are renewed every 30 days. Users can specify the maximum validity of the certificates while creating virtual services and ingress gateways. Maximum validity can range from 45 days to 90 days.

Changing mTLS Settings for a Deployed Mesh or Virtual Service 🔗

Changing the mTLS settings of a deployed mesh or virtual service might affect your applications uptime. To minimize any downtime, only move a mTLS setting to an adjacent setting. For example, to change the mTLS setting from DISABLED to STRICT, do the following:

1. Change from DISABLED to PERMISSIVE.
2. Then change from PERMISSIVE to STRICT.

DISABLED -> PERMISSIVE -> STRICT

STRICT -> PERMISSIVE -> DISABLED

More Security Information