Contribute in GitHub:

Configuring the Adaptive Proxy

Configuring the standalone version of the Adaptive Proxy

The Adaptive Proxy uses three configuration files:

adaptive.proxy.base.conf
adaptive.proxy.location.conf
adaptive.proxy.upstream.conf

In the standalone version of the Adaptive Proxy, you will find these in the workdir directory. Refer to the following sections for usage instructions:

adaptive.proxy.base.conf

This file maps each supported curve to a specific group. You can replace the socket names (qsc, hybrid, legacy, and x25519_kyber768) with passthrough.

Important: This is the only change you are allowed to make. You must not modify anything else in this file.

adaptive.proxy.location.conf

The adaptive.proxy.location.conf file enables the routing of requests to the correct location. It is used to define how the proxy server responds to requests for specific URIs. You can use the location URI to forward requests to another backend server.

For further details, see the Nginx http core module documentation.

adaptive.proxy.upstream.conf

The adaptive.proxy.upstream.conf file defines the backend servers used in the Adaptive Proxy configuration. The upstream directive is used to define groups of servers that can be referenced by directives such as proxy_pass.

For further details, see the Nginx http upstream module documentation.

Configuring the post-ingress version of the Adaptive Proxy

The main configuration changes you can make are the following:

certificate-generation/values.yaml

To update the Adaptive Proxy with new signature algorithms for generating TLS certificates, edit the section corresponding to the relevant signature algorithm group by replacing the values of type, root, intermediate, and leaf with your chosen algorithms:
```
<sig_alg_group>:
   type: qsc
   root: dilithium5
   intermediate: dilithium5
   leaf: dilithium5
```
Note: <sig_alg_group> can be any of the following depending on which signature algorithm group you are modifying:
- signAlgQSC
- signAlgHybrid
- signAlgLegacy
- signAlgDefault
templates/configmap.yaml

This file contains sections corresponding to the Nginx configuration files, such as adaptive.proxy.location.conf and adaptive.proxy.upstream.conf. Refer to Configuring the standalone version of the Adaptive Proxy for more information about how to use these sections.

Adding a new backend application to the post-ingress version of the Adaptive Proxy

To add a backend application to the post-ingress version of the Adaptive Proxy, open the templates/configmap.yaml file in your preferred text editor and complete the following steps:

Add the URL and port of the application to the adaptive.proxy.upstream.conf section using the following syntax:
```
adaptive.proxy.upstream.conf: |
    upstream <hostname> {
        server legacy-server-https.qs-sample-apps:6443;        
    }
```
Tips:
- Configure multiple upstream servers by adding additional upstream legacyHttpsBackend sections.
- The value of the server property must be in the format <endpoing_url>:<port_number> if the application is not deployed within the cluster, or <service_name>.<namespace>:<port> if it is.
- This configures the hostname to be the value of <hostname>.
- For additional information on how to use the configuration files, refer to Configuring the standalone version of the Adaptive Proxy.
Edit the adaptive.proxy.location.conf section:
```
adaptive.proxy.location.conf: |
location /testLegacy {
    proxy_pass https://<hostname>/;
}
```
Important: Use the same value for <hostname> that you configured in the adaptive.proxy.upstream.conf section.
Save the file and exit the text editor.
Run the installer again. This will read the configuration files and apply the changes to the existing resources.
```
./install.sh
```

Configuring the Adaptive Proxy as ingress controller

General configuration for the Adaptive Proxy as ingress controller

To configure the Adaptive Proxy as ingress controller, modify any of the following attributes of the init.properties file before you proceed with the installation. If you have already installed the Adaptive Proxy, you must reinstall it for the configuration changes to take effect.

Attribute name	Usage	Mandatory/Optional	Default value
cluster_name	Specify the the IKS/RHOS cluster name. This is required while setting up the NLB associated with the cluster	Mandatory
registry	Registry where Ingress Controller/Samples are placed before deployment.	Mandatory
hyperscaler	Name of the cloud. Takes only "ibm" as valid value	Mandatory	"ibm"
platform	Set openshift or iks	Mandatory	Set openshift for RHOS and iks for IKS
ingress_namespace	Namespace where PQC enabled ingress controller is deployed	Mandatory	q-safe-ngnix-ingress-namespace
app_namespace	Namespace where certificates are stored	Mandatory	q-safe-application-namespace
image_pull_secret	Secret name for image pull in RHOS/IKS	Mandatory	all-icr-io

Using the Adaptive Proxy as ingress controller for a new application

When you want the Adaptive Proxy as ingress controller to do the TLS offloading for a new application, you must use the following attributes in the ingress definition:

NLB domain name of the newly created NLB as the TLS host name
Use the secret name created above by the certificate generator
Use ingress-nginx-controller as ingressClassName

Use the following template for edge termination:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: # Name of your ingress
  namespace: # application namespace
  labels:
  annotations:

spec:
  tls:
    - hosts:
      - # service-prefix-subdomain.< NLB domain name>

      secretName: # secret created for edge termination 
  ingressClassName: ingress-nginx-controller
  rules:
    - host: #service-prefix-subdomain.< NLB domain name>
      http:
        paths:
          - path: /
            pathType: ImplementationSpecific
            backend:
              service:
                name: # name of the back end service
                port:
                  number: # application port

Use the following template for re-encrypt termination. The re-encryption is performed using the legacy-verify-secret secret, defined in the application namespace.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: # Name of the ingress
  namespace: # application namespace
  labels:
  annotations:
    nginx.ingress.kubernetes.io/proxy-ssl-secret:# application namespace/legacy-verify-secret
    nginx.ingress.kubernetes.io/proxy-ssl-verify: "off"
    nginx.ingress.kubernetes.io/backend-protocol: https
    nginx.ingress.kubernetes.io/proxy-ssl-protocols: TLSv1.2 TLSv1.3
    nginx.ingress.kubernetes.io/proxy-ssl-name: # service-prefix-subdomain.< NLB domain name>
spec:
  tls:
    - hosts:
      - # service-prefix-subdomain.< NLB domain name>
      secretName: edge-tls-secret
  ingressClassName: ingress-nginx-controller
  rules:
    - host: #service-prefix-subdomain.< NLB domain name>
      http:
        paths:
          - path: /
            pathType: ImplementationSpecific
            backend:
              service:
                name: # name of the back end service
                port:
                  number: # application port

Use the following template for passthrough:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: # Ingress name
  namespace: # Application namespace
  labels:
  annotations:

    nginx.ingress.kubernetes.io/ssl-passthrough: "true"
spec:
  ingressClassName: ingress-nginx-controller
  rules:
    - host: #service-prefix-subdomain.< NLB domain name>
      http:
        paths:
          - path: /
            pathType: ImplementationSpecific
            backend:
              service:
                name: # name of the back end service
                port:
                  number: # application port