Configure an ASM gateway for HTTPS access to a Knative Service - Alibaba Cloud Service Mesh

An Alibaba Cloud Service Mesh (ASM) gateway terminates TLS at the ingress layer, so external clients connect over HTTPS while internal traffic travels unencrypted to the Knative Service. The gateway dynamically loads TLS certificates from Kubernetes Secrets, which means you can rotate credentials without restarting gateway Pods.

This guide walks through creating a TLS certificate, storing it as a Kubernetes Secret, configuring the ASM gateway for HTTPS, and verifying end-to-end connectivity.

How it works

When a client sends an HTTPS request to a Knative Service:

The request reaches the ASM ingress gateway Pod in the istio-system namespace.
The gateway terminates TLS using the certificate and private key stored in a Kubernetes Secret.
The gateway forwards the decrypted request to the target Knative Service inside the mesh.

This setup encrypts traffic between external clients and the gateway. It does not encrypt traffic between internal mesh components. To encrypt service-to-service traffic inside the mesh, configure ASM mutual TLS (mTLS).

Prerequisites

Before you begin, ensure that you have:

A Knative Service deployed through Knative on ASM. For details, see Use Knative on ASM to deploy a serverless application
A custom domain name configured in Knative on ASM (this guide uses aliyun.com as an example). For details, see Set a custom domain name in Knative on ASM
An Internet Content Provider (ICP) filing for the domain name aliyun.com
OpenSSL installed on your local machine (required only for self-signed certificates)
kubectl configured with access to both the ASM control plane and the cluster that hosts the ingress gateway Pod

Step 1: Create a TLS certificate and private key

If you already have a valid certificate and private key for aliyun.com, rename them to aliyun.com.crt and aliyun.com.key, then skip to Store the certificate as a Kubernetes Secret.

To generate a self-signed certificate with OpenSSL:

Create a root certificate authority (CA):

   openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \
     -subj '/O=myexample Inc./CN=aliyun.com' \
     -keyout aliyun.root.key -out aliyun.root.crt

Generate a server certificate and private key signed by the root CA:

   openssl req -out aliyun.com.csr -newkey rsa:2048 -nodes \
     -keyout aliyun.com.key -subj "/CN=aliyun.com/O=myexample organization"

   openssl x509 -req -days 365 -CA aliyun.root.crt -CAkey aliyun.root.key \
     -set_serial 0 -in aliyun.com.csr -out aliyun.com.crt

Note

For production environments, use a certificate from a public Certificate Authority (CA) or integrate with cert-manager to automate certificate provisioning and renewal. Self-signed certificates are suitable for development and testing only.

Store the certificate as a Kubernetes Secret

Using the kubeconfig of the cluster that hosts the ingress gateway Pod, create a TLS Secret in the istio-system namespace:

kubectl create -n istio-system secret tls myexample-credential \
  --key=aliyun.com.key --cert=aliyun.com.crt

Note the Secret name (myexample-credential). You need it in the next step.

Step 2: Configure HTTPS on the ASM gateway

Save the following YAML as default.yaml: Replace the following values:

Field	Description
`domainName`	The custom domain name configured in Knative on ASM
`credentialName`	The name of the TLS Secret created in the previous step

   apiVersion: istio.alibabacloud.com/v1beta1
   kind: ASMKnativeConfig
   metadata:
     name: default
   spec:
     enabled: true
     useExisting: true
     tag: 1.4.0
     domainConfig:
       domainName: aliyun.com                  # Replace with your domain name.
       credentialName: myexample-credential     # Replace with your Secret name.

Connect kubectl to the ASM control plane and apply the configuration:
```
   kubectl apply -f default.yaml
```

Step 3: Verify HTTPS access

Update your local hosts file

Add a DNS mapping for the Knative Service domain to the ASM gateway IP address:

<gateway-ip>  helloworld-go.default.aliyun.com

Replace <gateway-ip> with the IP address of the ASM ingress gateway. To find this address, see Step 3: Query the gateway address in *Use Knative on ASM to deploy a serverless application*.

Test with curl

Send an HTTPS request to the Knative Service using the root CA for certificate verification:

curl --cacert aliyun.root.crt \
  --cert aliyun.com.crt --key aliyun.com.key \
  https://helloworld-go.default.aliyun.com

Expected output:

Hello Knative!

Note

The --cacert flag verifies the server certificate against the root CA you generated. If you used a certificate from a public CA, omit --cacert.

To skip certificate verification during quick testing with self-signed certificates, use the -k flag:

curl -k --cert aliyun.com.crt --key aliyun.com.key \
  https://helloworld-go.default.aliyun.com

Test with a browser

Open https://helloworld-go.default.aliyun.com in a browser.

Note

Browsers display a security warning for self-signed certificates. This is expected and does not indicate a configuration problem.

Troubleshooting

Symptom	Possible cause	Resolution
`connection refused` on port 443	The ASMKnativeConfig was not applied, or the gateway Pod has not reloaded	Run `kubectl get asmknativeconfig default -o yaml` to verify the config. Check gateway Pod logs for errors.
TLS handshake failure	The Secret name in ASMKnativeConfig does not match the Secret in `istio-system`	Run `kubectl get secret -n istio-system` to confirm the Secret exists and the name matches `credentialName`.
`certificate verify failed` with curl	The `--cacert` flag points to the wrong CA certificate	Pass the root CA (`aliyun.root.crt`), not the server certificate.
Browser shows "Not Secure" warning	A self-signed certificate is in use	Expected for self-signed certificates. Use a certificate from a public CA for production.
`404 Not Found` after applying config	The domain name in ASMKnativeConfig does not match the Knative Service domain	Verify that `domainName` matches the domain configured in Knative on ASM.

What's next

Canary releases with traffic splitting: Knative on ASM supports canary releases based on traffic splitting. When you create a Knative Service, Knative automatically creates the first Revision. Each time the Service configuration changes, Knative creates a new Revision and adjusts the percentage of traffic distributed to different Revisions. For details, see Perform a canary release based on traffic splitting for a Knative Service by using Knative on ASM.
Request-based Pod autoscaling: Knative Serving adds a Queue Proxy container to each Pod. The Queue Proxy container reports concurrency metrics to the Knative Pod Autoscaler (KPA). Based on these metrics, KPA automatically adjusts the number of Pods provisioned for a Deployment according to the number of concurrent requests and related autoscaling algorithms. For details, see Enable autoscaling of Pods based on the number of requests.