This is a cache of https://docs.openshift.com/serverless/1.33/knative-serving/config-custom-domains/domain-mapping-odc-admin.html. It is a snapshot of the page at 2024-11-29T16:40:52.728+0000.
Domain mapping using the Administrator perspective - Configuring custom domains for Knative services | Serving | Red Hat OpenShift Serverless 1.33
×

If you do not want to switch to the Developer perspective in the OpenShift Container Platform web console or use the Knative (kn) CLI or YAML files, you can use the Administator perspective of the OpenShift Container Platform web console.

Mapping a custom domain to a service by using the Administrator perspective

Knative services are automatically assigned a default domain name based on your cluster configuration. For example, <service_name>-<namespace>.example.com. You can customize the domain for your Knative service by mapping a custom domain name that you own to a Knative service.

You can do this by creating a DomainMapping resource for the service. You can also create multiple DomainMapping resources to map multiple domains and subdomains to a single service.

If you have cluster administrator permissions on OpenShift Container Platform (or cluster or dedicated administrator permissions on OpenShift Dedicated or Red Hat OpenShift Service on AWS), you can create a DomainMapping custom resource (CR) by using the Administrator perspective in the web console.

Prerequisites
  • You have logged in to the web console.

  • You are in the Administrator perspective.

  • You have installed the OpenShift Serverless Operator.

  • You have installed Knative Serving.

  • You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads.

  • You have created a Knative service and control a custom domain that you want to map to that service.

    Your custom domain must point to the IP address of the cluster.

Procedure
  1. Navigate to CustomResourceDefinitions and use the search box to find the DomainMapping custom resource definition (CRD).

  2. Click the DomainMapping CRD, then navigate to the Instances tab.

  3. Click Create DomainMapping.

  4. Modify the YAML for the DomainMapping CR so that it includes the following information for your instance:

    apiVersion: serving.knative.dev/v1beta1
    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
    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 domain mapping to a Knative service
    apiVersion: serving.knative.dev/v1beta1
    kind: DomainMapping
    metadata:
     name: custom-ksvc-domain.example.com
     namespace: default
    spec:
     ref:
       name: showcase
       kind: Service
       apiVersion: serving.knative.dev/v1
Verification
  • Access the custom domain by using a curl request. For example:

    Example command
    $ curl custom-ksvc-domain.example.com
    Example output
    {"artifact":"knative-showcase","greeting":"Welcome"}

Restricting cipher suites by using the Administrator perspective

When you specify net-kourier for ingress and use DomainMapping, the TLS for OpenShift routing is set to passthrough, and TLS is handled by the Kourier Gateway. In such cases, you might need to restrict which TLS cipher suites for Kourier are allowed for users.

Prerequisites
  • You have logged in to the web console.

  • You are in the Administrator perspective.

  • You have installed the OpenShift Serverless Operator.

  • You have installed Knative Serving.

  • You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads.

    Your custom domain must point to the IP address of the cluster.

Procedure
  • In the KnativeServing CR, use the cipher-suites value to specify the cipher suites you want to enable:

    KnativeServing CR example
    spec:
      config:
        kourier:
          cipher-suites: ECDHE-ECDSA-AES128-GCM-SHA256,ECDHE-ECDSA-CHACHA20-POLY1305

    Other cipher suites will be disabled. You can specify multiple suites by separating them with commas.

    The Kourier Gateway’s container image utilizes the Envoy proxy image, and the default enabled cipher suites depend on the version of the Envoy proxy.