Service Mesh offers various application security features. This section provides an overview of those features and discusses implementation details.
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:
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
STRICT. In addition, there can
be a mix of virtual services some at
PERMISSIVE, some at
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:
- Traffic from a virtual service is considered within a mesh traffic.
- Traffic from an ingress gateway is considered within a mesh traffic.
- 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.
We recommend that you do not edit the certificate validity or renewal periods directly in Certificate Service. Certificate Service limits the number of certificate versions to 30. After the number of versions reach 30, automatic renewal fails. To avoid failures during certificate renewal, delete old certificates in a timely manner.
The certificates are automatically renewed every two thirds of a certificate's validity time. For example, if the maximum validity period is 60 days, the certificate is renewed every (2/3)*60 = 40 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
STRICT, do the following:
- Change from
- Then change from
The order of state change from
DISABLED -> PERMISSIVE -> STRICT
The principal is applied in reverse as well. To change the state from
STRICT -> PERMISSIVE -> DISABLED
Going directly from
DISABLEDcould result in your mesh being inaccessible for several minutes. Wait for the propagation delay, a minimum of 30 seconds between the two steps.