主页
产品
OpenShift Container Platform
4.5
Service Mesh
1.9. Customizing security in a Service Mesh

1.9. Customizing security in a Service Mesh

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 can help you manage the complexity of your applications and provide service and identity security for microservices.

1.9.1. Enabling mutual Transport Layer Security (mTLS)
复制链接

Mutual Transport Layer Security (mTLS) is a protocol where two parties authenticate each other at the same time. It is the default mode of authentication in some protocols (IKE, SSH) and optional in others (TLS).

MTLS can be used 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, Red Hat OpenShift Service Mesh is 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 is communicating with a service outside the mesh, strict mTLS could break communication between those services. Use permissive mode while you migrate your workloads to Service Mesh.

1.9.1.1. Enabling strict mTLS across the mesh
复制链接

If your workloads do not communicate with services outside your mesh and communication will not be interrupted by only accepting encrypted connections, you can enable mTLS across your mesh quickly. Set spec.istio.global.mtls.enabled to true in your ServiceMeshControlPlane resource. The operator creates the required resources.

apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
  istio:
    global:
      mtls:
        enabled: true

apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
  istio:
    global:
      mtls:
        enabled: true

Copy to Clipboard

Toggle word wrap

1.9.1.1.1. Configuring sidecars for incoming connections for specific services
复制链接

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

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: "default"
  namespace: <NAMESPACE>
spec:
  peers:
  - mtls: {}

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: "default"
  namespace: <NAMESPACE>
spec:
  peers:
  - mtls: {}

Copy to Clipboard

Toggle word wrap

1.9.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.

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

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

Copy to Clipboard

Toggle word wrap

1.9.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.istio.global.tls.minProtocolVersion or spec.istio.global.tls.maxProtocolVersion in your ServiceMeshControlPlane resource. Those values, configured in your control plane resource, define the minimum and maximum TLS version used by mesh components when communicating securely over TLS.

apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
  istio:
    global:
      tls:
        minProtocolVersion: TLSv1_0

apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
  istio:
    global:
      tls:
        minProtocolVersion: TLSv1_0

Copy to Clipboard

Toggle word wrap

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

Expand

表 1.14. 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

1.9.2. Configuring cipher suites and ECDH curves
复制链接

Cipher suites and Elliptic-curve Diffie–Hellman (ECDH curves) can help you secure your service mesh. You can define a comma separated list of cipher suites using spec.istio.global.tls.cipherSuites and ECDH curves using spec.istio.global.tls.ecdhCurves in your ServiceMeshControlPlane resource. If either of these attributes are empty, then the default values are used.

The cipherSuites setting is effective if your service mesh uses TLS 1.2 or earlier. It has no effect when negotiating with TLS 1.3.

Set your cipher suites in the comma separated list in order of priority. For example, ecdhCurves: CurveP256, CurveP384 sets CurveP256 as a higher priority than CurveP384.

注意

You must include either TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 or TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 when you configure the cipher suite. HTTP/2 support requires at least one of these cipher suites.

The supported cipher suites are:

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

The supported ECDH Curves are:

CurveP256
CurveP384
CurveP521
X25519

1.9.3. Adding an external certificate authority key and certificate
复制链接

By default, Red Hat OpenShift Service Mesh generates self-signed root certificate and key, and uses them to sign the workload certificates. You can also use the user-defined certificate and key to sign workload certificates, with user-defined root certificate. This task demonstrates an example to plug certificates and key into Service Mesh.

Prerequisites

You must have installed Red Hat OpenShift Service Mesh with mutual TLS enabled to configure certificates.
This example uses the certificates from the Maistra repository. For production, use your own certificates from your certificate authority.
You must deploy the Bookinfo sample application to verify the results with these instructions.

1.9.3.1. Adding an existing certificate and key
复制链接

To use an existing signing (CA) certificate and key, you must create a chain of trust file that includes the CA certificate, key, and root certificate. You must use the following exact file names for each of the corresponding certificates. The CA certificate is called ca-cert.pem, the key is ca-key.pem, and the root certificate, which signs ca-cert.pem, is called root-cert.pem. If your workload uses intermediate certificates, you must specify them in a cert-chain.pem file.

Add the certificates to Service Mesh by following these steps. Save the example certificates from the Maistra repository locally and replace <path> with the path to your certificates.

Create a secret cacert that includes the input files ca-cert.pem, ca-key.pem, root-cert.pem and cert-chain.pem.

oc create secret generic cacerts -n istio-system --from-file=<path>/ca-cert.pem \
    --from-file=<path>/ca-key.pem --from-file=<path>/root-cert.pem \
    --from-file=<path>/cert-chain.pem

$ oc create secret generic cacerts -n istio-system --from-file=<path>/ca-cert.pem \
    --from-file=<path>/ca-key.pem --from-file=<path>/root-cert.pem \
    --from-file=<path>/cert-chain.pem

Copy to Clipboard

Toggle word wrap

In the ServiceMeshControlPlane resource set global.mtls.enabled to true and security.selfSigned set to false. Service Mesh reads the certificates and key from the secret-mount files.

apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
  istio:
    global:
      mtls:
        enabled: true
    security:
      selfSigned: false

apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
  istio:
    global:
      mtls:
        enabled: true
    security:
      selfSigned: false

Copy to Clipboard

Toggle word wrap

To make sure the workloads add the new certificates promptly, delete the secrets generated by Service Mesh, named istio.*. In this example, istio.default. Service Mesh issues new certificates for the workloads.
```
oc delete secret istio.default
```
```
$ oc delete secret istio.default
```
Copy to Clipboard Toggle word wrap

1.9.3.2. Verifying your certificates
复制链接

Use the Bookinfo sample application to verify your certificates are mounted correctly. First, retrieve the mounted certificates. Then, verify the certificates mounted on the pod.

Store the pod name in the variable RATINGSPOD.

RATINGSPOD=`oc get pods -l app=ratings -o jsonpath='{.items[0].metadata.name}'`

$ RATINGSPOD=`oc get pods -l app=ratings -o jsonpath='{.items[0].metadata.name}'`

Copy to Clipboard

Toggle word wrap

Run the following commands to retrieve the certificates mounted on the proxy.

oc exec -it $RATINGSPOD -c istio-proxy -- /bin/cat /etc/certs/root-cert.pem > /tmp/pod-root-cert.pem

$ oc exec -it $RATINGSPOD -c istio-proxy -- /bin/cat /etc/certs/root-cert.pem > /tmp/pod-root-cert.pem

Copy to Clipboard

Toggle word wrap

The file /tmp/pod-root-cert.pem contains the root certificate propagated to the pod.

oc exec -it $RATINGSPOD -c istio-proxy -- /bin/cat /etc/certs/cert-chain.pem > /tmp/pod-cert-chain.pem

$ oc exec -it $RATINGSPOD -c istio-proxy -- /bin/cat /etc/certs/cert-chain.pem > /tmp/pod-cert-chain.pem

Copy to Clipboard

Toggle word wrap

The file /tmp/pod-cert-chain.pem contains the workload certificate and the CA certificate propagated to the pod.

Verify the root certificate is the same as the one specified by the Operator. Replace <path> with the path to your certificates.

openssl x509 -in <path>/root-cert.pem -text -noout > /tmp/root-cert.crt.txt

$ openssl x509 -in <path>/root-cert.pem -text -noout > /tmp/root-cert.crt.txt

Copy to Clipboard

Toggle word wrap

openssl x509 -in /tmp/pod-root-cert.pem -text -noout > /tmp/pod-root-cert.crt.txt

$ openssl x509 -in /tmp/pod-root-cert.pem -text -noout > /tmp/pod-root-cert.crt.txt

Copy to Clipboard

Toggle word wrap

diff /tmp/root-cert.crt.txt /tmp/pod-root-cert.crt.txt

$ diff /tmp/root-cert.crt.txt /tmp/pod-root-cert.crt.txt

Copy to Clipboard

Toggle word wrap

Expect the output to be empty.

Verify the CA certificate is the same as the one specified by Operator. Replace <path> with the path to your certificates.

sed '0,/^-----END CERTIFICATE-----/d' /tmp/pod-cert-chain.pem > /tmp/pod-cert-chain-ca.pem

$ sed '0,/^-----END CERTIFICATE-----/d' /tmp/pod-cert-chain.pem > /tmp/pod-cert-chain-ca.pem

Copy to Clipboard

Toggle word wrap

openssl x509 -in <path>/ca-cert.pem -text -noout > /tmp/ca-cert.crt.txt

$ openssl x509 -in <path>/ca-cert.pem -text -noout > /tmp/ca-cert.crt.txt

Copy to Clipboard

Toggle word wrap

openssl x509 -in /tmp/pod-cert-chain-ca.pem -text -noout > /tmp/pod-cert-chain-ca.crt.txt

$ openssl x509 -in /tmp/pod-cert-chain-ca.pem -text -noout > /tmp/pod-cert-chain-ca.crt.txt

Copy to Clipboard

Toggle word wrap

diff /tmp/ca-cert.crt.txt /tmp/pod-cert-chain-ca.crt.txt

$ diff /tmp/ca-cert.crt.txt /tmp/pod-cert-chain-ca.crt.txt

Copy to Clipboard

Toggle word wrap

Expect the output to be empty.

Verify the certificate chain from the root certificate to the workload certificate. Replace <path> with the path to your certificates.

head -n 21 /tmp/pod-cert-chain.pem > /tmp/pod-cert-chain-workload.pem

$ head -n 21 /tmp/pod-cert-chain.pem > /tmp/pod-cert-chain-workload.pem

Copy to Clipboard

Toggle word wrap

openssl verify -CAfile <(cat <path>/ca-cert.pem <path>/root-cert.pem) /tmp/pod-cert-chain-workload.pem

$ openssl verify -CAfile <(cat <path>/ca-cert.pem <path>/root-cert.pem) /tmp/pod-cert-chain-workload.pem

Copy to Clipboard

Toggle word wrap

Example output

/tmp/pod-cert-chain-workload.pem: OK

/tmp/pod-cert-chain-workload.pem: OK

Copy to Clipboard

Toggle word wrap

1.9.3.3. Removing the certificates
复制链接

To remove the certificates you added, follow these steps.

Remove the secret cacerts.

oc delete secret cacerts -n istio-system

$ oc delete secret cacerts -n istio-system

Copy to Clipboard

Toggle word wrap

Redeploy Service Mesh with a self-signed root certificate in the ServiceMeshControlPlane resource.

apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
  istio:
    global:
      mtls:
        enabled: true
    security:
      selfSigned: true

apiVersion: maistra.io/v1
kind: ServiceMeshControlPlane
spec:
  istio:
    global:
      mtls:
        enabled: true
    security:
      selfSigned: true

Copy to Clipboard

Toggle word wrap

返回顶部

1.9. Customizing security in a Service Mesh

1.9.1. Enabling mutual Transport Layer Security (mTLS)
复制链接

1.9.1.1. Enabling strict mTLS across the mesh
复制链接

1.9.1.1.1. Configuring sidecars for incoming connections for specific services
复制链接

1.9.1.2. Configuring sidecars for outgoing connections
复制链接

1.9.1.3. Setting the minimum and maximum protocol versions
复制链接

1.9.2. Configuring cipher suites and ECDH curves
复制链接

1.9.3. Adding an external certificate authority key and certificate
复制链接

1.9.3.1. Adding an existing certificate and key
复制链接

1.9.3.2. Verifying your certificates
复制链接

1.9.3.3. Removing the certificates
复制链接

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

1.9. Customizing security in a Service Mesh

1.9.1. Enabling mutual Transport Layer Security (mTLS)复制链接链接已复制到粘贴板!

1.9.1.1. Enabling strict mTLS across the mesh复制链接链接已复制到粘贴板!

1.9.1.1.1. Configuring sidecars for incoming connections for specific services复制链接链接已复制到粘贴板!

1.9.1.2. Configuring sidecars for outgoing connections复制链接链接已复制到粘贴板!

1.9.1.3. Setting the minimum and maximum protocol versions复制链接链接已复制到粘贴板!

1.9.2. Configuring cipher suites and ECDH curves复制链接链接已复制到粘贴板!

1.9.3. Adding an external certificate authority key and certificate复制链接链接已复制到粘贴板!

1.9.3.1. Adding an existing certificate and key复制链接链接已复制到粘贴板!

1.9.3.2. Verifying your certificates复制链接链接已复制到粘贴板!

1.9.3.3. Removing the certificates复制链接链接已复制到粘贴板!

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

1.9.1. Enabling mutual Transport Layer Security (mTLS)
复制链接

1.9.1.1. Enabling strict mTLS across the mesh
复制链接

1.9.1.1.1. Configuring sidecars for incoming connections for specific services
复制链接

1.9.1.2. Configuring sidecars for outgoing connections
复制链接

1.9.1.3. Setting the minimum and maximum protocol versions
复制链接

1.9.2. Configuring cipher suites and ECDH curves
复制链接

1.9.3. Adding an external certificate authority key and certificate
复制链接

1.9.3.1. Adding an existing certificate and key
复制链接

1.9.3.2. Verifying your certificates
复制链接

1.9.3.3. Removing the certificates
复制链接