Chapter 10. Security

Procedure

1. Add the sidecar.istio.io/inject="true" annotation to your service:

   Example service

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: <service_name>
   spec:
     template:
       metadata:
         annotations:
           sidecar.istio.io/inject: "true" 

   1

   
           sidecar.istio.io/rewriteAppHTTPProbers: "true" 

   2

   
   ...

   Copy to Clipboard Toggle word wrap

   1

   Add the sidecar.istio.io/inject="true" annotation.

   2

   You must set the annotation sidecar.istio.io/rewriteAppHTTPProbers: "true" in your Knative service, because OpenShift Serverless versions 1.14.0 and higher use an HTTP probe as the readiness probe for Knative services by default.

2. Apply the Service resource:

   $ oc apply -f <filename>

   Copy to Clipboard Toggle word wrap

3. Create a RequestAuthentication resource in each serverless application namespace that is a member in the ServiceMeshMemberRoll object:

   apiVersion: security.istio.io/v1beta1
   kind: RequestAuthentication
   metadata:
     name: jwt-example
     namespace: <namespace>
   spec:
     jwtRules:
     - issuer: testing@secure.istio.io
       jwksUri: https://raw.githubusercontent.com/istio/istio/release-1.8/security/tools/jwt/samples/jwks.json

   Copy to Clipboard Toggle word wrap

4. Apply the RequestAuthentication resource:

   $ oc apply -f <filename>

   Copy to Clipboard Toggle word wrap

5. Allow access to the RequestAuthenticaton resource from system pods for each serverless application namespace that is a member in the ServiceMeshMemberRoll object, by creating the following AuthorizationPolicy resource:

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allowlist-by-paths
     namespace: <namespace>
   spec:
     action: ALLOW
     rules:
     - to:
       - operation:
           paths:
           - /metrics 

   1

   
           - /healthz 

   2

   Copy to Clipboard Toggle word wrap

   1

   The path on your application to collect metrics by system pod.

   2

   The path on your application to probe by system pod.

6. Apply the AuthorizationPolicy resource:

   $ oc apply -f <filename>

   Copy to Clipboard Toggle word wrap

7. For each serverless application namespace that is a member in the ServiceMeshMemberRoll object, create the following AuthorizationPolicy resource:

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: require-jwt
     namespace: <namespace>
   spec:
     action: ALLOW
     rules:
     - from:
       - source:
          requestPrincipals: ["testing@secure.istio.io/testing@secure.istio.io"]

   Copy to Clipboard Toggle word wrap

8. Apply the AuthorizationPolicy resource:

   $ oc apply -f <filename>

   Copy to Clipboard Toggle word wrap

Verification

1. If you try to use a curl request to get the Knative service URL, it is denied:

   Example command

   $ curl http://hello-example-1-default.apps.mycluster.example.com/

   Copy to Clipboard Toggle word wrap

   Example output

   RBAC: access denied

   Copy to Clipboard Toggle word wrap

2. Verify the request with a valid JWT.

   1. Get the valid JWT token:

      $ TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.8/security/tools/jwt/samples/demo.jwt -s) && echo "$TOKEN" | cut -d '.' -f2 - | base64 --decode -

      Copy to Clipboard Toggle word wrap

   2. Access the service by using the valid token in the curl request header:

      $ curl -H "Authorization: Bearer $TOKEN"  http://hello-example-1-default.apps.example.com

      Copy to Clipboard Toggle word wrap

      The request is now allowed:

      Example output

      Hello OpenShift!

      Copy to Clipboard Toggle word wrap

Procedure

1. Add the sidecar.istio.io/inject="true" annotation to your service:

   Example service

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: <service_name>
   spec:
     template:
       metadata:
         annotations:
           sidecar.istio.io/inject: "true" 

   1

   
           sidecar.istio.io/rewriteAppHTTPProbers: "true" 

   2

   
   ...

   Copy to Clipboard Toggle word wrap

   1

   Add the sidecar.istio.io/inject="true" annotation.

   2

   You must set the annotation sidecar.istio.io/rewriteAppHTTPProbers: "true" in your Knative service, because OpenShift Serverless versions 1.14.0 and higher use an HTTP probe as the readiness probe for Knative services by default.

2. Apply the Service resource:

   $ oc apply -f <filename>

   Copy to Clipboard Toggle word wrap

3. Create a policy in a serverless application namespace which is a member in the ServiceMeshMemberRoll object, that only allows requests with valid JSON Web Tokens (JWT):

   Important

   The paths /metrics and /healthz must be included in excludedPaths because they are accessed from system pods in the knative-serving namespace.

   apiVersion: authentication.istio.io/v1alpha1
   kind: Policy
   metadata:
     name: default
     namespace: <namespace>
   spec:
     origins:
     - jwt:
         issuer: testing@secure.istio.io
         jwksUri: "https://raw.githubusercontent.com/istio/istio/release-1.6/security/tools/jwt/samples/jwks.json"
         triggerRules:
         - excludedPaths:
           - prefix: /metrics 

   1

   
           - prefix: /healthz 

   2

   
     principalBinding: USE_ORIGIN

   Copy to Clipboard Toggle word wrap

   1

   The path on your application to collect metrics by system pod.

   2

   The path on your application to probe by system pod.

4. Apply the Policy resource:

   $ oc apply -f <filename>

   Copy to Clipboard Toggle word wrap

Verification

1. If you try to use a curl request to get the Knative service URL, it is denied:

   $ curl http://hello-example-default.apps.mycluster.example.com/

   Copy to Clipboard Toggle word wrap

   Example output

   Origin authentication failed.

   Copy to Clipboard Toggle word wrap

2. Verify the request with a valid JWT.

   1. Get the valid JWT token:

      $ TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.6/security/tools/jwt/samples/demo.jwt -s) && echo "$TOKEN" | cut -d '.' -f2 - | base64 --decode -

      Copy to Clipboard Toggle word wrap

   2. Access the service by using the valid token in the curl request header:

      $ curl http://hello-example-default.apps.mycluster.example.com/ -H "Authorization: Bearer $TOKEN"

      Copy to Clipboard Toggle word wrap

      The request is now allowed:

      Example output

      Hello OpenShift!

      Copy to Clipboard Toggle word wrap

Procedure

1. Create a YAML file containing the DomainMapping CR in the same namespace as the target CR you want to map to:

   apiVersion: serving.knative.dev/v1alpha1
   kind: DomainMapping
   metadata:
    name: <domain_name> 

   1

   
    namespace: <namespace> 

   2

   
   spec:
    ref:
      name: <target_name> 

   3

   
      kind: <target_type> 

   4

   
      apiVersion: serving.knative.dev/v1

   Copy to Clipboard Toggle word wrap

   1

   The custom domain name that you want to map to the target CR.

   2

   The namespace of both the DomainMapping CR and the target CR.

   3

   The name of the target CR to map to the custom domain.

   4

   The type of CR being mapped to the custom domain.

   Example service domain mapping

   apiVersion: serving.knative.dev/v1alpha1
   kind: DomainMapping
   metadata:
    name: example.com
    namespace: default
   spec:
    ref:
      name: example-service
      kind: Service
      apiVersion: serving.knative.dev/v1

   Copy to Clipboard Toggle word wrap

   Example route domain mapping

   apiVersion: serving.knative.dev/v1alpha1
   kind: DomainMapping
   metadata:
    name: example.com
    namespace: default
   spec:
    ref:
      name: example-route
      kind: Route
      apiVersion: serving.knative.dev/v1

   Copy to Clipboard Toggle word wrap

2. Apply the DomainMapping CR as a YAML file:

   $ oc apply -f <filename>

   Copy to Clipboard Toggle word wrap

Procedure

1. Create a Kubernetes TLS secret:

   $ oc create secret tls <tls_secret_name> --cert=<path_to_certificate_file> --key=<path_to_key_file>

   Copy to Clipboard Toggle word wrap

2. If you are using Red Hat OpenShift Service Mesh as the ingress for your OpenShift Serverless installation, label the Kubernetes TLS secret with the following:

   “networking.internal.knative.dev/certificate-uid": “<value>”

   Copy to Clipboard Toggle word wrap

   If you are using a third-party secret provider such as cert-manager, you can configure your secret manager to label the Kubernetes TLS secret automatically. Cert-manager users can use the secret template offered to automatically generate secrets with the correct label. In this case, secret filtering is done based on the key only, but this value can carry useful information such as the certificate ID that the secret contains.

   Note

   The {cert-manager-operator} is a Technology Preview feature. For more information, see the Installing the {cert-manager-operator} documentation.

3. Update the DomainMapping CR to use the TLS secret that you have created:

   apiVersion: serving.knative.dev/v1alpha1
   kind: DomainMapping
   metadata:
     name: <domain_name>
     namespace: <namespace>
   spec:
     ref:
       name: <service_name>
       kind: Service
       apiVersion: serving.knative.dev/v1
   # TLS block specifies the secret to be used
     tls:
       secretName: <tls_secret_name>

   Copy to Clipboard Toggle word wrap

Verification

1. Verify that the DomainMapping CR status is True, and that the URL column of the output shows the mapped domain with the scheme https:

   $ oc get domainmapping <domain_name>

   Copy to Clipboard Toggle word wrap

   Example output

   NAME                      URL                               READY   REASON
   example.com               https://example.com               True

   Copy to Clipboard Toggle word wrap

2. Optional: If the service is exposed publicly, verify that it is available by running the following command:

   $ curl https://<domain_name>

   Copy to Clipboard Toggle word wrap

   If the certificate is self-signed, skip verification by adding the -k flag to the curl command.