1.13. Security

If your service mesh application is constructed with a complex array of microservices, you can use Red Hat OpenShift Service Mesh to customize the security of the communication between those services. The infrastructure of OpenShift Container Platform along with the traffic management features of Service Mesh help you manage the complexity of your applications and secure microservices.

Before you begin

If you have a project, add your project to the ServiceMeshMemberRoll resource.

If you don’t have a project, install the Bookinfo sample application and add it to the ServiceMeshMemberRoll resource. The sample application helps illustrate security concepts.

1.13.1. About mutual Transport Layer Security (mTLS)
링크 복사

Mutual Transport Layer Security (mTLS) is a protocol that enables two parties to authenticate each other. It is the default mode of authentication in some protocols (IKE, SSH) and optional in others (TLS). You can use mTLS without changes to the application or service code. The TLS is handled entirely by the service mesh infrastructure and between the two sidecar proxies.

By default, mTLS in Red Hat OpenShift Service Mesh is enabled and set to permissive mode, where the sidecars in Service Mesh accept both plain-text traffic and connections that are encrypted using mTLS. If a service in your mesh configured to use strict mTLS is communicating with a service outside the mesh, communication might break between those services because strict mTLS requires both the client and the server to be able to verify the identify of each other. Use permissive mode while you migrate your workloads to Service Mesh. Then, you can enable strict mTLS across your mesh, namespace, or application.

Enabling mTLS across your mesh at the Service Mesh control plane level secures all the traffic in your service mesh without rewriting your applications and workloads. You can secure namespaces in your mesh at the data plane level in the ServiceMeshControlPlane resource. To customize traffic encryption connections, configure namespaces at the application level with PeerAuthentication and DestinationRule resources.

1.13.1.1. Enabling strict mTLS across the service mesh
링크 복사

If your workloads do not communicate with outside services, you can quickly enable mTLS across your mesh without communication interruptions. You can enable it by setting spec.security.dataPlane.mtls to true in the ServiceMeshControlPlane resource. The Operator creates the required resources.

apiVersion: maistra.io/v2
kind: ServiceMeshControlPlane
spec:
  version: v2.5
  security:
    dataPlane:
      mtls: true

You can also enable mTLS by using the OpenShift Container Platform web console.

Procedure

Log in to the web console.
Click the Project menu and select the project where you installed the Service Mesh control plane, for example istio-system.
Click Operators Installed Operators.
Click Service Mesh Control Plane under Provided APIs.
Click the name of your ServiceMeshControlPlane resource, for example, basic.
On the Details page, click the toggle in the Security section for Data Plane Security.

1.13.1.1.1. Configuring sidecars for incoming connections for specific services
링크 복사

You can also configure mTLS for individual services by creating a policy.

Procedure

Create a YAML file using the following example.

PeerAuthentication Policy example policy.yaml

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: <namespace>
spec:
  mtls:
    mode: STRICT

Replace <namespace> with the namespace where the service is located.

Run the following command to create the resource in the namespace where the service is located. It must match the namespace field in the Policy resource you just created.
```
$ oc create -n <namespace> -f <policy.yaml>
```

참고

If you are not using automatic mTLS and you are setting PeerAuthentication to STRICT, you must create a DestinationRule resource for your service.

1.13.1.1.2. Configuring sidecars for outgoing connections
링크 복사

Create a destination rule to configure Service Mesh to use mTLS when sending requests to other services in the mesh.

Procedure

Create a YAML file using the following example.

DestinationRule example destination-rule.yaml

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: default
  namespace: <namespace>
spec:
  host: "*.<namespace>.svc.cluster.local"
  trafficPolicy:
   tls:
    mode: ISTIO_MUTUAL

Replace <namespace> with the namespace where the service is located.

Run the following command to create the resource in the namespace where the service is located. It must match the namespace field in the DestinationRule resource you just created.
```
$ oc create -n <namespace> -f <destination-rule.yaml>
```

1.13.1.1.3. Setting the minimum and maximum protocol versions
링크 복사

If your environment has specific requirements for encrypted traffic in your service mesh, you can control the cryptographic functions that are allowed by setting the spec.security.controlPlane.tls.minProtocolVersion or spec.security.controlPlane.tls.maxProtocolVersion in your ServiceMeshControlPlane resource. Those values, configured in your Service Mesh control plane resource, define the minimum and maximum TLS version used by mesh components when communicating securely over TLS.

The default is TLS_AUTO and does not specify a version of TLS.

Expand

표 1.5. Valid values
Value	Description
`TLS_AUTO`	default
`TLSv1_0`	TLS version 1.0
`TLSv1_1`	TLS version 1.1
`TLSv1_2`	TLS version 1.2
`TLSv1_3`	TLS version 1.3

Procedure

Log in to the web console.
Click the Project menu and select the project where you installed the Service Mesh control plane, for example istio-system.
Click Operators Installed Operators.
Click Service Mesh Control Plane under Provided APIs.
Click the name of your ServiceMeshControlPlane resource, for example, basic.
Click the YAML tab.
Insert the following code snippet in the YAML editor. Replace the value in the minProtocolVersion with the TLS version value. In this example, the minimum TLS version is set to TLSv1_2.
ServiceMeshControlPlane snippet
```
kind: ServiceMeshControlPlane
spec:
  security:
    controlPlane:
      tls:
        minProtocolVersion: TLSv1_2
```
Click Save.
Click Refresh to verify that the changes updated correctly.

1.13.1.2. Validating encryption with Kiali
링크 복사

The Kiali console offers several ways to validate whether or not your applications, services, and workloads have mTLS encryption enabled.

그림 1.5. Masthead icon mesh-wide mTLS enabled

At the right side of the masthead, Kiali shows a lock icon when the mesh has strictly enabled mTLS for the whole service mesh. It means that all communications in the mesh use mTLS.

그림 1.6. Masthead icon mesh-wide mTLS partially enabled

Kiali displays a hollow lock icon when either the mesh is configured in PERMISSIVE mode or there is a error in the mesh-wide mTLS configuration.

그림 1.7. Security badge

The Graph page has the option to display a Security badge on the graph edges to indicate that mTLS is enabled. To enable security badges on the graph, from the Display menu, under Show Badges, select the Security checkbox. When an edge shows a lock icon, it means at least one request with mTLS enabled is present. In case there are both mTLS and non-mTLS requests, the side-panel will show the percentage of requests that use mTLS.

The Applications Detail Overview page displays a Security icon on the graph edges where at least one request with mTLS enabled is present.

The Workloads Detail Overview page displays a Security icon on the graph edges where at least one request with mTLS enabled is present.

The Services Detail Overview page displays a Security icon on the graph edges where at least one request with mTLS enabled is present. Also note that Kiali displays a lock icon in the Network section next to ports that are configured for mTLS.

1.13. Security

1.13.1. About mutual Transport Layer Security (mTLS)
링크 복사

1.13.1.1. Enabling strict mTLS across the service mesh
링크 복사

1.13.1.1.1. Configuring sidecars for incoming connections for specific services
링크 복사

1.13.1.1.2. Configuring sidecars for outgoing connections
링크 복사

1.13.1.1.3. Setting the minimum and maximum protocol versions
링크 복사

1.13.1.2. Validating encryption with Kiali
링크 복사

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat 문서 정보

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

1.13. Security

1.13.1. About mutual Transport Layer Security (mTLS)링크 복사링크가 클립보드에 복사되었습니다!

1.13.1.1. Enabling strict mTLS across the service mesh링크 복사링크가 클립보드에 복사되었습니다!

1.13.1.1.1. Configuring sidecars for incoming connections for specific services링크 복사링크가 클립보드에 복사되었습니다!

1.13.1.1.2. Configuring sidecars for outgoing connections링크 복사링크가 클립보드에 복사되었습니다!

1.13.1.1.3. Setting the minimum and maximum protocol versions링크 복사링크가 클립보드에 복사되었습니다!

1.13.1.2. Validating encryption with Kiali링크 복사링크가 클립보드에 복사되었습니다!

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat 문서 정보

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

1.13.1. About mutual Transport Layer Security (mTLS)
링크 복사

1.13.1.1. Enabling strict mTLS across the service mesh
링크 복사

1.13.1.1.1. Configuring sidecars for incoming connections for specific services
링크 복사

1.13.1.1.2. Configuring sidecars for outgoing connections
링크 복사

1.13.1.1.3. Setting the minimum and maximum protocol versions
링크 복사

1.13.1.2. Validating encryption with Kiali
링크 복사