Configure HTTPS mutual authentication for ALB Ingresses to enhance service security - Container Compute Service

The HTTPS mutual authentication mechanism ensures that the server and client can verify the identity of each other. You can use HTTPS mutual authentication to guarantee information security in scenarios such as finance, IoT, enterprise internal service, and public service sectors that involve private information.

Comparison between HTTPS one-way authentication and HTTPS mutual authentication

HTTPS one-way authentication: The client downloads the SSL or TLS certificate from the server to verify the identity of the server and establishes a secure channel. The server cannot verify the identity of the client.
HTTPS mutual authentication: The client downloads the SSL or TLS certificate from the server to verify the identity of the server. Meanwhile, the client sends its SSL or TLS certificate to the server as a proof of its identity. A secure channel is established only after the client and server verify the identity of each other. In most cases, the server holds the certificate authority (CA) certificate and the client holds the SSL or TLS certificate signed and issued based on the root CA certificate. Therefore, the server can verify the identity of the client. Using HTTPS mutual authentication allows you to expose services only to trusted clients, which can prevent man-in-the-middle attacks and enhance service security.

Prerequisites

An SSL or TLS certificate is configured by following the steps in Configure HTTPS Certificates for Encrypted Communication.
A root CA certificate is obtained. You can obtain a root CA certificate in one of the following ways:
- Purchase a certificate in the Certificate Management Service console. For more information, see Purchase and enable a private CA.
- Follow the steps in this topic to generate a self-signed certificate.

(Optional) Step 1: Generate a self-signed a root CA certificate

You can perform the following steps to generate a root CA certificate and upload the certificate to the Certificate Management Service console.

Run the following command to create a private key:
```
openssl genrsa -out ca.key 4096
```

Run the following command to create a certificate signing request (CSR):

openssl req -new -out ca.csr -key ca.key

After you run the preceding commands, the system prompts you to specify information about the certificate. The following sample code block shows the parameters and sample values:

Country Name (2 letter code) [XX]:cn
State or Province Name (full name) []:bj
Locality Name (eg, city) [Default City]:bj
Organization Name (eg, company) [Default Company Ltd]:alibaba
Organizational Unit Name (eg, section) []:test
Common Name (eg, your name or your servers hostname) []:root
Email Address []:a.alibaba.com
A challenge password []:
An optional company name []:

The following table describes the parameters.

Parameter	Description
Country Name	The country code, which is a two-letter code. For example, cn represents China. This parameter is required.
State or Province Name	The state or province name. This parameter is required.
Locality Name	The city name. This parameter is required.
Organization Name	The organization name, for example, a company name. This parameter is required.
Organizational Unit Name	The organization unit name. This parameter is required.
Common Name	The domain name for which the certificate is used. This parameter is optional.
Email Address	The email address that is used to contact the certificate administrator. This parameter is optional.
A challenge password	The password that is used to authenticate access to the CSR. This parameter is optional. In this example, this parameter is left empty.
An optional company name	The company name. This parameter is optional. In this example, this parameter is left empty.

Run the following command to create a root CA certificate:
```
openssl x509 -req -in ca.csr -out ca.crt -signkey ca.key -CAcreateserial -days 3650
```
After the preceding operations are performed, run the ls command to view the private key file and certificate file of the root certificate in the current directory.
```
ca.crt ca.csr ca.key
```
The ca.crt file is the root certificate issued by a CA. The ca.csr file is the CSR sent to a CA. The ca.key file is the private key. The ca.key and ca.crt files are used in Step 7 to configure a self-signed root CA certificate.
Important
You must keep the private key confidential.
Log on to the Certificate Management Service console. In the left-side navigation pane, click Certificate Application Repository.

On the Certificate Application Repository page, click Create Repository. In the Create Repository panel, set the following parameters and click OK.

Parameter		Description
Repository Name		The name of the repository. You can specify a custom name.
Data Source		In this example, click Uploaded Certificates and then select a private certificate purchased and issued from a third-party certificate service provider.

On the Certificate Application Repository page, click the repository that you created. On the Manage Certificates page, click Uploaded Certificates.

In the CA Information panel, set the parameters based on the following table to upload the CA certificate that you created in Step 3 and click Confirm and Enable.

Parameter	Description
Package Name	Enter a custom name for the certificate that you want to upload.
CA Certificates	Enter the content of the PEM-encoded file of the certificate that you want to upload. You can use a text editor to open the certificate file in the PEM or CRT format. Then, copy the content to the CA Certificates field. You can also click Upload and then select the certificate file from your on-premises machine to upload the content of the file.
Certificate Key	Enter the content of the PEM-encoded file of the certificate that you want to upload.

Step 2: Generate a client certificate

You can purchase a client certificate from the Certificate Management Service console. You can also issue a client certificate by using a self-signed CA certificate.

In the following examples, the self-signed CA certificate created in Step 1 is used to issue a client certificate, and mutual authentication is enabled for a listener based on the self-signed client certificate and server certificate that you created.

Run the following command to generate a private key for the client certificate:
```
openssl genrsa -out client.key 4096
```
Run the following command to generate a CSR for creating a client certificate:
```
openssl req -new -out client.csr -key client.key
```
Run the following commands to generate a client certificate:
```
openssl x509 -req -in client.csr -out client.crt -signkey client.key -CA ca.crt -CAkey ca.key -CAcreateserial -days 3650
```
CA and CAkey correspond to the root certificate created in Step 1.
After the preceding operations are performed, run the ls command to view the generated client certificate in the current directory.
```
client.crt client.csr client.key
```

Step 3: Create an AlbConfig to enable mutual authentication for a listener

Specify the server certificate created in Step 1 in the Certificates parameter of an AlbConfig. The certificate is set as the default server certificate.
1. Log on to the Certificate Management Service console. In the left-side navigation pane, click SSL Certificates.
2. On the SSL Certificates page, click the icon in the Actions column and click Details.
3. In the Certificate Details panel, you can view the certificate information.
Specify the identifier of the root certificate created in Step 1 in the CertificateId field of the CaCertificates parameter of the AlbConfig.
1. Log on to the Certificate Management Service console. In the left-side navigation pane, click Certificate Application Repository.
2. On the Certificate Application Repository page, click the repository that you created. On the Manage Certificates page, click Details.
3. In the Certificate Details panel, you can view the identifier of the certificate.

Sample AlbConfig configuration:

apiVersion: alibabacloud.com/v1
kind: AlbConfig
metadata:
  name: alb-demo
spec:
  config:
    name: alb-test
    addressType: Intranet
# Specify at least two vSwitches that reside in different zones. Make sure that the zones are supported by Application Load Balancer (ALB) and belong to the same virtual private cloud (VPC) as the cluster.     
    zoneMappings:
    - vSwitchId: vsw-2zednnurkug2xl4******
    - vSwitchId: vsw-2zeusdspvojoumx******
  listeners:
  - port: 443
    protocol: HTTPS
    caEnabled: true
    caCertificates:
    - CertificateId: 0e40dda998174723af39d37fcaf*****
    certificates:
    - CertificateId: 108*****-cn-hangzhou
      IsDefault: true

Step 4: Test mutual authentication

Create a file named coffee.yaml and copy the following code block to the file. The file is used to deploy a test service exposed by an Ingress. The service is associated with the listener configured in Step 3.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: coffee
spec:
  replicas: 2
  selector:
    matchLabels:
      app: coffee
  template:
    metadata:
      labels:
        app: coffee
    spec:
      containers:
      - name: coffee
        image: registry.cn-hangzhou.aliyuncs.com/acs-sample/nginxdemos:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: coffee-svc
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
  selector:
    app: coffee
  type: NodePort
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/listen-ports: |
     [{"HTTPS": 443}]
  name: alb-ingress
spec:
  ingressClassName: alb
  rules:
  - host: alb.ingress.alibaba.com # Add a DNS record for this domain name. 
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: coffee-svc
            port:
              number: 80

Run the following command to deploy a test service:

kubectl apply -f coffee.yaml

Expected output:

deployment.apps/coffee created
service/coffee-svc created
ingress.networking.k8s.io/alb-ingress created

Use the client certificate generated in Step 2 to access the service.
1. Log on to the ALB console. In the top navigation bar, select the region where the ALB instance is deployed.
2. On the Instances page, click the ALB instance.
3. In the Zone section of the instance details page, obtain the elastic IP address (EIP) that is associated with the vSwitch of the ALB instance.
4. Add a DNS record to the hosts file to map the domain name to the EIP.
```
123.XX.XX.XX alb.ingress.alibaba.com
```
5. After the DNS record is added, you can access the service by using the domain name.
```
Replace alb.ingress.alibaba.com with the actual domain name that you want to use. You must also specify the paths of the client.crt and client.key files. 
curl https://alb.ingress.alibaba.com/ --cert client.crt --key client.key
```
  After you run the command, the server returns a response to redirect you to an HTML page.

References

If errors occur when you use ALB, refer to the ALB documentation first. For more information, see ALB Ingress controller troubleshooting and FAQ about ALB Ingresses.