Expose and secure kyma workloads with client certificates and kyma-system defined mTLS gateways

Expose and secure kyma workloads with client certificates and kyma-system defined mTLS gateways.md

2. Expose and secure kyma workloads with client certificates and kyma-system defined mTLS gateways

The following kyma tutorial details a number of pre-requisite steps, namely:

• having a dedicated custom domain for mTLS communication with a mutual TLS gateway
• and creating a cacert bundle for the server side certificate validation.

However, any managed kyma cluster domain is also a custom domain (and managed by SAP).

Thus, it is possible to reuse this kyma cluster domain "as is" by adding a dedicated mutual TLS gateway.

 

Table of Contents add a dedicated custom sub-domain of a kyma cluster domain create a mTLS kyma-system namespace gateway Create a base64-encoded cacert bundle. [Istio] Configure a Virtual Service. [Istio] Configure Authorization Policy

2.1 add a dedicated custom sub-domain of a kyma cluster domain

Let's go to istio-system namespace and create a certificate resource for our mTLS domain, as depicted below: You can use the below certificate resource manifest template for your own mTLS sub-domain.

apiVersion: cert.gardener.cloud/v1alpha1
kind: Certificate
metadata:
  name: mtls-certs
  namespace: istio-system
spec:
  commonName: mtls.<shoot>.stage.kyma.ondemand.com
  dnsNames:
    - '*.mtls.<shoot>.stage.kyma.ondemand.com'
  secretRef:
    name: mtls-certs
    namespace: istio-system

Good to know:

• the CN of the certificate must be a fixed domain name as the wildcard domain name is already served by the default kyma-system gateway.
• worth mentioning, this is possible thanks to the built-in DNS automation that comes along with managed kyma runtime environment

2.2 create a mTLS kyma-system namespaced gateway

 

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: kyma-gateway-mtls
  namespace: kyma-system
spec:
  selector:
    app: istio-ingressgateway
    istio: ingressgateway
  servers:
    - hosts:
        - mtls.<shoot>.stage.kyma.ondemand.com
      port:
        name: mtls
        number: 443
        protocol: HTTPS
      tls:
        credentialName: mtls-certs
        minProtocolVersion: TLSV1_2
        mode: MUTUAL

 

2.3 Create a base64-encoded cacert bundle

As aforementioned, the cacert bundle is composed of two public x509 certificates, namely the client's x509 issuer certificate and the root CA certificate.

$ cat poster-quovadis-cacert.pem | base64
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUdhRENDQkZDZ0F3SUJBZ0lUY0FBQUFBV2FYN3FEWCsxMzZBQUFBQUFBQ0Y0SlRiTzhBTll0V1FUeDBQVnJaS0p1KzhmY0lhVXA3TVZCSVZaCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0=

kind: Secret
apiVersion: v1
metadata:
  name: mtls-certs-cacert
  namespace: istio-system
data:
  cacert: >-
    LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUdhRENDQkZDZ0F3SUJBZ0lUY0FBQUFBV2FYN3FEWCsxMzZBQUFBQUFBQ0Y0SlRiTzhBTll0V1FUeDBQVnJaS0p1KzhmY0lhVXA3TVZCSVZaCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0=
type: Opaque

 

2.4 Configure a Virtual Service for x509 client authentication.

The API rules do not yet support the x509 client certificate authentication. Thus, we need configure a VirtualService to allow for the x509 client certificate communication, as follows:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-mtls
  namespace: quovadis
spec:
  gateways:
    - kyma-system/kyma-gateway-mtls
  hosts:
    - mtls.<shoot>.stage.kyma.ondemand.com
  http:
    - corsPolicy:
        allowHeaders:
          - Authorization
          - Content-Type
          - '*'
        allowMethods:
          - GET
          - POST
          - PUT
          - DELETE
          - PATCH
        allowOrigins:
          - regex: .*
      headers:
        request:
          set:
            X-CLIENT-SSL-CN: '%DOWNSTREAM_PEER_SUBJECT%'
            X-CLIENT-SSL-ISSUER: '%DOWNSTREAM_PEER_ISSUER%'
            X-CLIENT-SSL-SAN: '%DOWNSTREAM_PEER_URI_SAN%'
            test: 'true'
            x-forwarded-host: mtls.<shoot>.stage.kyma.ondemand.com
      match:
        - uri:
            regex: /.*
      route:
        - destination:
            host: httpbin.quovadis.svc.cluster.local
            port:
              number: 8000
          weight: 100
      timeout: 300s

2.5 Configure Authorization Policy

Please observe that the below policy is restricted to workloads against kyma-system/kyma-gateway-mtls gateway with the PolicyTargetReference mechanism.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: httpbin-mtls-policy
  namespace: quovadis
spec:
  action: ALLOW
  rules:
    - to:
        - operation:
            hosts:
              - mtls.<shoot>.stage.kyma.ondemand.com
      when:
        - key: request.headers[X-Client-Ssl-Cn]
          values:
            - >-
              CN=poster-quovadis
              (P000000),L=<sap ias tenant>accounts400.ondemand.com,OU=8e1affb2-62a1-43cc-a687-***,OU=Canary,OU=SAP
              Cloud Platform Clients,O=SAP SE,C=DE
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: kyma-gateway-mtls

 

Additional reading

Secure Application Communications with Mutual TLS and Istio | Istio docs

Secure service-service communication with Istio |Medium Blogs

Service Mesh by example — how we did it | Medium Blogs