diff --git a/_topic_map.yml b/_topic_map.yml index 9e0ad2164e7a..3d8d26395c95 100644 --- a/_topic_map.yml +++ b/_topic_map.yml @@ -3071,8 +3071,6 @@ Topics: File: serverless-ossm-with-kourier-jwt - Name: Configuring a custom domain for a Knative service File: serverless-custom-domains - - Name: Configuring TLS for a custom domain using Kourier - File: serverless-ossm-tls-with-kourier - Name: Using a custom TLS certificate for domain mapping File: serverless-custom-tls-cert-domain-mapping # diff --git a/modules/knative-service-cluster-local.adoc b/modules/knative-service-cluster-local.adoc index 4bcff664c718..a262261c5661 100644 --- a/modules/knative-service-cluster-local.adoc +++ b/modules/knative-service-cluster-local.adoc @@ -1,5 +1,5 @@ [id="knative-service-cluster-local_{context}"] -= Setting cluster availability to `cluster-local` += Setting cluster availability to cluster local By default, Knative services are published to a public IP address. Being published to a public IP address means that Knative services are public applications, and have a publicly accessible URL. @@ -19,7 +19,6 @@ For {ServerlessProductName} 1.15.0 and newer versions, the `serving.knative.dev/ * Set the visibility for your service by adding the `networking.knative.dev/visibility=cluster-local` label: + - [source,terminal] ---- $ oc label ksvc networking.knative.dev/visibility=cluster-local @@ -29,14 +28,11 @@ $ oc label ksvc networking.knative.dev/visibility=cluster-local * Check that the URL for your service is now in the format `\http://..svc.cluster.local`, by entering the following command and reviewing the output: + - [source,termina] ---- $ oc get ksvc ---- - + - .Example output [source,terminal] ---- diff --git a/modules/serverless-access-custom-domain.adoc b/modules/serverless-access-custom-domain.adoc deleted file mode 100644 index f1adf08fee31..000000000000 --- a/modules/serverless-access-custom-domain.adoc +++ /dev/null @@ -1,26 +0,0 @@ -// Module included in the following assemblies: -// -// * serverless/networking/serverless-ossm-custom-domains.adoc - -[id="serverless-access-custom-domain_{context}"] -= Accessing a service using your custom domain - -.Procedure - -. Access the custom domain by using the `Host` header in a `curl` request. For example: -+ - -[source,terminal] ----- -$ curl -H "Host: custom-ksvc-domain.example.com" http:// ----- - -+ -where `` is the IP address that the {product-title} ingress router is exposed to. -+ - -.Example output -[source,terminal] ----- -Hello OpenShift! ----- diff --git a/modules/serverless-ossm-v1x-tls.adoc b/modules/serverless-ossm-v1x-tls.adoc deleted file mode 100644 index 4d9cffbeb7e9..000000000000 --- a/modules/serverless-ossm-v1x-tls.adoc +++ /dev/null @@ -1,158 +0,0 @@ -[id="serverless-ossm-v1x-tls_{context}"] -= Configuring Transport Layer Security for a custom domain using {ProductName} 1.x - -You can create a Transport Layer Security (TLS) key and certificates for a custom domain and subdomain using {ProductName}. - -.Procedure - -. Create a root certificate and private key to sign the certificates for your services: -+ -[source,terminal] ----- -$ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \ - -subj '/O=Example Inc./CN=example.com' \ - -keyout example.com.key \ - -out example.com.crt ----- -. Create a certificate signing request for your domain: -+ -[source,terminal] ----- -$ openssl req -out custom.example.com.csr -newkey rsa:2048 -nodes \ - -keyout custom.example.com.key \ - -subj "/CN=custom-ksvc-domain.example.com/O=Example Inc." ----- -. Sign the request with your CA: -+ -[source,terminal] ----- -$ openssl x509 -req -days 365 -set_serial 0 \ - -CA example.com.crt \ - -CAkey example.com.key \ - -in custom.example.com.csr \ - -out custom.example.com.crt ----- -. Check that the certificates appear in your directory: -+ -[source,terminal] ----- -$ ls -1 ----- -+ -.Example output -[source,terminal] ----- -custom.example.com.crt -custom.example.com.csr -custom.example.com.key -example.com.crt -example.com.key ----- -. Create a secret: -+ -[source,terminal] ----- -$ oc create -n istio-system secret tls custom.example.com \ - --key=custom.example.com.key \ - --cert=custom.example.com.crt ----- -. Attach the secret to the Istio ingress gateway by editing the `ServiceMeshControlPlane` resource. -.. Edit the `ServiceMeshControlPlane` resource: -+ -[source,terminal] ----- -$ oc edit -n istio-system ServiceMeshControlPlane ----- -.. Check that the following lines exist in the resource, and if they do not, add them: -+ -[source,yaml] ----- -spec: - istio: - gateways: - istio-ingressgateway: - secretVolumes: - - mountPath: /custom.example.com - name: custom-example-com - secretName: custom.example.com ----- -. Update the Istio ingress gateway to use your secret. -.. Edit the `default-gateway` resource: -+ -[source,terminal] ----- -$ oc edit gateway default-gateway ----- -.. Check that the following lines exist in the resource, and if they do not, add them: -+ -[source,yaml] ----- -- hosts: - - custom-ksvc-domain.example.com - port: - name: https - number: 443 - protocol: HTTPS - tls: - mode: SIMPLE - privateKey: /custom.example.com/tls.key - serverCertificate: /custom.example.com/tls.crt ----- -. Update the route to use pass-through TLS and `8443` as the `spec.port.targetPort`. -.. Edit the route: -+ -[source,terminal] ----- -$ oc edit route -n istio-system hello ----- -.. Add the following configuration to the route: -+ -[source,yaml] ----- -spec: - host: custom-ksvc-domain.example.com - port: - targetPort: 8443 - tls: - insecureEdgeTerminationPolicy: None - termination: passthrough - to: - kind: Service - name: istio-ingressgateway - weight: 100 - wildcardPolicy: None ----- - -.Verification - -* Access your serverless application by a secure connection that is now trusted by the CA: -+ -[source,terminal] ----- -$ curl --cacert example.com.crt \ - --header "Host: custom-ksvc-domain.example.com" \ - --resolve "custom-ksvc-domain.example.com:443:" \ - https://custom-ksvc-domain.example.com:443 ----- -+ -[NOTE] -==== -You must substitute your own value for ``. -Steps for finding this IP or hostname value vary depending on your {product-title} provider platform. - -.Example command to find the ingress IP - -This command is valid for GCP and Azure provider platforms: - -[source,terminal] ----- -$ oc get svc -n openshift-ingress router-default \ - -o jsonpath='{.status.loadBalancer.ingress[0].ip}' ----- -==== -+ -.Example output -[source,terminal] ----- -Hello OpenShift! ----- diff --git a/modules/serverless-ossm-v2x-tls.adoc b/modules/serverless-ossm-v2x-tls.adoc deleted file mode 100644 index 145209c284d4..000000000000 --- a/modules/serverless-ossm-v2x-tls.adoc +++ /dev/null @@ -1,160 +0,0 @@ -[id="serverless-ossm-v2x-tls_{context}"] -= Configuring Transport Layer Security for a custom domain using {ProductName} 2.x - -You can create a Transport Layer Security (TLS) key and certificates for a custom domain and subdomain using {ProductName}. - -.Procedure - -. Create a root certificate and private key to sign the certificates for your services: -+ -[source,terminal] ----- -$ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \ - -subj '/O=Example Inc./CN=example.com' \ - -keyout example.com.key \ - -out example.com.crt ----- -. Create a certificate signing request for your domain: -+ -[source,terminal] ----- -$ openssl req -out custom.example.com.csr -newkey rsa:2048 -nodes \ - -keyout custom.example.com.key \ - -subj "/CN=custom-ksvc-domain.example.com/O=Example Inc." ----- -. Sign the request with your CA: -+ -[source,terminal] ----- -$ openssl x509 -req -days 365 -set_serial 0 \ - -CA example.com.crt \ - -CAkey example.com.key \ - -in custom.example.com.csr \ - -out custom.example.com.crt ----- -. Check that the certificates appear in your directory: -+ -[source,terminal] ----- -$ ls -1 ----- -+ -.Example output -[source,terminal] ----- -custom.example.com.crt -custom.example.com.csr -custom.example.com.key -example.com.crt -example.com.key ----- -. Create a secret: -+ -[source,terminal] ----- -$ oc create -n istio-system secret tls custom.example.com \ - --key=custom.example.com.key \ - --cert=custom.example.com.crt ----- -. Attach the secret to the Istio ingress gateway by editing the `ServiceMeshControlPlane` resource. -.. Edit the `ServiceMeshControlPlane` resource: -+ -[source,terminal] ----- -$ oc edit -n istio-system ServiceMeshControlPlane ----- -.. Check that the following lines exist in the resource, and if they do not, add them: -+ -[source,yaml] ----- -spec: - gateways: - ingress: - volumes: - - volume: - secret: - secretName: custom.example.com - volumeMount: - name: custom-example-com - mountPath: /custom.example.com ----- -. Update the Istio ingress gateway to use your secret. -.. Edit the `default-gateway` resource: -+ -[source,terminal] ----- -$ oc edit gateway default-gateway ----- -.. Check that the following lines exist in the resource, and if they do not, add them: -+ -[source,yaml] ----- -- hosts: - - custom-ksvc-domain.example.com - port: - name: https - number: 443 - protocol: HTTPS - tls: - mode: SIMPLE - privateKey: /custom.example.com/tls.key - serverCertificate: /custom.example.com/tls.crt ----- -. Update the route to use pass-through TLS and `8443` as the `spec.port.targetPort`. -.. Edit the route: -+ -[source,terminal] ----- -$ oc edit route -n istio-system hello ----- -.. Add the following configuration to the route: -+ -[source,yaml] ----- -spec: - host: custom-ksvc-domain.example.com - port: - targetPort: 8443 - tls: - insecureEdgeTerminationPolicy: None - termination: passthrough - to: - kind: Service - name: istio-ingressgateway - weight: 100 - wildcardPolicy: None ----- - -.Verification - -* Access your serverless application by a secure connection that is now trusted by the CA: -+ -[source,terminal] ----- -$ curl --cacert example.com.crt \ - --header "Host: custom-ksvc-domain.example.com" \ - --resolve "custom-ksvc-domain.example.com:443:" \ - https://custom-ksvc-domain.example.com:443 ----- -+ -[NOTE] -==== -You must substitute your own value for ``. -Steps for finding this IP or hostname value vary depending on your {product-title} provider platform. - -.Example command to find the ingress IP - -This command is valid for GCP and Azure provider platforms: - -[source,terminal] ----- -$ oc get svc -n openshift-ingress router-default \ - -o jsonpath='{.status.loadBalancer.ingress[0].ip}' ----- -==== -+ -.Example output -[source,terminal] ----- -Hello OpenShift! ----- diff --git a/modules/serverless-service-mesh-resources.adoc b/modules/serverless-service-mesh-resources.adoc deleted file mode 100644 index 46a27cf3f458..000000000000 --- a/modules/serverless-service-mesh-resources.adoc +++ /dev/null @@ -1,117 +0,0 @@ -[id="serverless-service-mesh-resources_{context}"] -= Creating necessary {ProductShortName} resources - -To use custom domains with {ProductShortName}, you must first create some necessary {ProductShortName} resources. - -.Procedure - -. Create an Istio gateway to accept traffic: -+ -[source,yaml] ----- -apiVersion: networking.istio.io/v1alpha3 -kind: Gateway -metadata: - name: <1> -spec: - selector: - istio: ingressgateway - servers: - - port: - number: 80 - name: http - protocol: HTTP - hosts: - - "*" ----- -<1> The namespace where your Knative services have been created. This namespace must be a member of the Service Mesh member roll. -. Apply the `Gateway` resource: -+ -[source,terminal] ----- -$ oc apply -f ----- -. Create an Istio virtual service to rewrite the host header: -+ -[source,yaml] ----- -apiVersion: networking.istio.io/v1alpha3 -kind: VirtualService -metadata: - name: hello -spec: - hosts: - - custom-ksvc-domain.example.com - gateways: - - default-gateway - http: - - rewrite: - authority: hello.default.svc <1> - route: - - destination: - host: hello.default.svc <1> - port: - number: 80 ----- -<1> Your Knative service in the format `..svc`. -. Apply the `VirtualService` resource: -+ -[source,terminal] ----- -$ oc apply -f ----- - -. Create an Istio service entry. This is required for {ServerlessProductName} because Kourier is outside of the {ProductShortName}: -+ -[source,yaml] ----- -apiVersion: networking.istio.io/v1alpha3 -kind: ServiceEntry -metadata: - name: hello.default.svc -spec: - hosts: - - hello.default.svc <1> - location: MESH_EXTERNAL - endpoints: - - address: kourier-internal.knative-serving-ingress.svc - ports: - - number: 80 - name: http - protocol: HTTP - resolution: DNS ----- -<1> Your Knative service in the format `..svc`. -. Apply the `ServiceEntry` resource: -+ -[source,terminal] ----- -$ oc apply -f ----- - -. Create an {product-title} route that points to the `VirtualService` object: -+ -[source,yaml] ----- -apiVersion: route.openshift.io/v1 -kind: Route -metadata: - name: hello - namespace: istio-system <1> -spec: - host: custom-ksvc-domain.example.com - port: - targetPort: 8080 - to: - kind: Service - name: istio-ingressgateway ----- -<1> The {product-title} route must be created in the same namespace as the -`ServiceMeshControlPlane`. In this example, the `ServiceMeshControlPlane` is -deployed in the `istio-system` namespace. -. Apply the `Route` resource: -+ -[source,terminal] ----- -$ oc apply -f ----- diff --git a/serverless/cli_tools/kn-serving-ref.adoc b/serverless/cli_tools/kn-serving-ref.adoc index 9b7b0ea46604..bc24ba2fc0c1 100644 --- a/serverless/cli_tools/kn-serving-ref.adoc +++ b/serverless/cli_tools/kn-serving-ref.adoc @@ -18,15 +18,12 @@ include::modules/kn-service-update.adoc[leveloffset=+2] include::modules/kn-service-apply.adoc[leveloffset=+2] include::modules/kn-service-describe.adoc[leveloffset=+2] -//// [id="kn-serving-ref-kn-container"] == kn container commands You can use the following commands to create and manage multiple containers in a Knative service spec. include::modules/serverless-kn-container.adoc[leveloffset=+2] -//// -// Uncomment at 1.19.0 release [id="kn-serving-ref-domain-mapping"] == kn domain commands diff --git a/serverless/knative_serving/serverless-applications.adoc b/serverless/knative_serving/serverless-applications.adoc index fe91bc048d73..a3bffa0d8fef 100644 --- a/serverless/knative_serving/serverless-applications.adoc +++ b/serverless/knative_serving/serverless-applications.adoc @@ -13,7 +13,7 @@ include::modules/serverless-apps-intro.adoc[leveloffset=+1] You can create a serverless application by using one of the following methods: -* Create a Knative service from the {product-title} web console. +* Create a Knative service from the {product-title} web console. See the documentation about xref:../../applications/creating_applications/odc-creating-applications-using-developer-perspective.adoc#odc-creating-applications-using-developer-perspective[Creating applications using the Developer perspective]. * Create a Knative service using the `kn` CLI. * Create and apply a YAML file. @@ -26,8 +26,7 @@ For more information about creating applications using the *Developer* perspecti // create service using CLI include::modules/creating-serverless-apps-kn.adoc[leveloffset=+2] -// Uncomment at 1.19.0 -// include::modules/serverless-kn-container.adoc[leveloffset=+3] +include::modules/serverless-kn-container.adoc[leveloffset=+3] // create service using YAML include::modules/creating-serverless-apps-yaml.adoc[leveloffset=+2] diff --git a/serverless/security/serverless-custom-domains.adoc b/serverless/security/serverless-custom-domains.adoc index 01ad0cf24a3a..faceffc98257 100644 --- a/serverless/security/serverless-custom-domains.adoc +++ b/serverless/security/serverless-custom-domains.adoc @@ -13,43 +13,3 @@ You can customize the domain for your Knative service by mapping a custom domain include::modules/serverless-create-domain-mapping.adoc[leveloffset=+1] include::modules/serverless-create-domain-mapping-kn.adoc[leveloffset=+1] - -[id="serverless-custom-domains-private-services"] -== Configuring custom domains for private Knative services - -:FeatureName: Configuring custom domains for private Knative services - -[IMPORTANT] -==== -{FeatureName} is a deprecated feature. Deprecated functionality is still included in {product-title} and continues to be supported; however, it will be removed in a future release of this product and is not recommended for new deployments. - -Refer to xref:../../serverless/security/serverless-custom-domains.adoc#serverless-create-domain-mapping_serverless-custom-domains[Creating a custom domain mapping] for the latest documentation. -==== - -:!FeatureName: - -You can configure a custom domain for an existing Knative service by completing the following procedures. - -[IMPORTANT] -==== -This method of configuring custom domains is only supported for clusters that have Kourier enabled. If you want to configure custom domains using only {ServerlessProductName} with {ProductShortName}, without Kourier enabled, use the `DomainMapping` resources method instead. -==== - -.Prerequisites - -* The {ServerlessOperatorName} and Knative Serving are installed on your {product-title} cluster. -* {ProductName} version 1.x or 2.x is installed on your cluster, and the integration between {ProductName} and {ServerlessProductName} has been correctly configured. - -[IMPORTANT] -==== -{ServerlessProductName} only supports the use of {ProductName} functionality that is explicitly documented in this guide, and does not support other undocumented features. -==== - -include::modules/knative-service-cluster-local.adoc[leveloffset=+2] -include::modules/serverless-service-mesh-resources.adoc[leveloffset=+2] -include::modules/serverless-access-custom-domain.adoc[leveloffset=+2] - -[id="additional-resources_serverless-ossm-custom-domains"] -== Additional resources - -* For more information about {ProductName}, see xref:../../service_mesh/v1x/ossm-architecture.adoc#ossm-architecture-v1x[Understanding {ProductName}]. diff --git a/serverless/security/serverless-ossm-tls-with-kourier.adoc b/serverless/security/serverless-ossm-tls-with-kourier.adoc deleted file mode 100644 index 62236be5d84f..000000000000 --- a/serverless/security/serverless-ossm-tls-with-kourier.adoc +++ /dev/null @@ -1,48 +0,0 @@ -include::modules/serverless-document-attributes.adoc[] -include::modules/ossm-document-attributes.adoc[] -[id="serverless-ossm-tls-with-kourier"] -= Configuring TLS for a custom domain using Kourier -:context: serverless-ossm-tls -include::modules/common-attributes.adoc[] - -toc::[] - -:FeatureName: Configuring TLS for a custom domain using Kourier - -include::modules/deprecated-feature.adoc[leveloffset=+1] - -:!FeatureName: - -You can create a Transport Layer Security (TLS) key and certificates for a custom domain and subdomain using {ProductName}. - -[IMPORTANT] -==== -{ServerlessProductName} only supports the use of {ProductName} functionality that is explicitly documented in this guide, and does not support other undocumented features. -==== - -[id="prerequisites_serverless-ossm-tls"] -== Prerequisites - -* Install xref:../../serverless/admin_guide/install-serverless-operator.adoc#install-serverless-operator[{ServerlessProductName}]. -* Install {ProductName} xref:../../service_mesh/v1x/installing-ossm.adoc#installing-ossm-v1x[1.x] or xref:../../service_mesh/v2x/installing-ossm.adoc#installing-ossm-v2x[2.x]. -+ -[IMPORTANT] -==== -{ServerlessProductName} is compatible only with full implementations of either {ProductName} 1.x or 2.x. {ServerlessProductName} does not support custom usage of some 1.x resources and some 2.x resources in the same deployment. For example, upgrading to 2.x while still using the control plane `maistra.io/v1` spec is not supported. -==== -* Complete the configuration steps in xref:../../serverless/admin_guide/serverless-ossm-setup.adoc#serverless-ossm-setup-with-kourier_serverless-ossm-setup[Integrating {ProductShortName} and {ServerlessProductName} with Kourier enabled]. -* Configure a custom domain. See xref:../../serverless/security/serverless-custom-domains.adoc#serverless-custom-domains[Configuring a custom domain for a Knative service]. -* In this example, `openssl` is used to generate certificates, but you can use any certificate generation tool to create these. - -[IMPORTANT] -==== -This example uses the `example.com` domain. -The example certificate for this domain is used as a certificate authority (CA) that signs the subdomain certificate. - -To complete and verify this procedure in your deployment, you need either a certificate signed by a widely trusted public CA, or a CA provided by your organization. - -Example commands must be adjusted according to your domain, subdomain and CA. -==== - -include::modules/serverless-ossm-v2x-tls.adoc[leveloffset=+1] -include::modules/serverless-ossm-v1x-tls.adoc[leveloffset=+1]