Customizing ALB routing

Adding a server port to a host header

To add a server port to the client request before the request is forwarded to your back-end app, configure a proxy to external services in a server snippet annotation or as an ibm-k8s-controller-config ConfigMap field.

Routing incoming requests with a private ALB

To route incoming requests to your apps with a private ALB, specify the private-iks-k8s-nginx class annotation in the Ingress resource. Private ALBs are configured to use resources with this class.

kubernetes.io/ingress.class: "private-iks-k8s-nginx"

Authenticating apps with App ID

Configure Ingress with IBM Cloud App ID to enforce authentication for your apps by changing specific Kubernetes Ingress fields. See Adding App ID authentication to apps for more information.

Setting the maximum client request body size

To set the maximum size of the body that the client can send as part of a request, use the following Kubernetes Ingress resource annotation.

nginx.ingress.kubernetes.io/proxy-body-size: 8m

Enabling and disabling client response data buffering

You can disable or enable the storage of response data on the ALB while the data is sent to the client. This setting is disabled by default. To enable, set the following Ingress resource annotation.

nginx.ingress.kubernetes.io/proxy-buffering: "on"

Customizing connect and read timeouts

To set the amount of time that the ALB waits to connect to and read from the back-end app before the back-end app is considered unavailable, use the following annotations.

nginx.ingress.kubernetes.io/proxy-connect-timeout: 62

nginx.ingress.kubernetes.io/proxy-read-timeout: 62

Customizing error actions

To indicate custom actions that the ALB can take for specific HTTP errors, set the custom-http-errors field.

Changing the default HTTP and HTTPS ports

To change the default ports for HTTP (port 80) and HTTPS (port 443) network traffic, modify each ALB service with the following Kubernetes Ingress ibm-ingress-deploy-config ConfigMap fields.

Example field setting.

httpPort=8080
httpsPort=8443

Customizing the request header

To add header information to a client request before forwarding the request to your back-end app, use the following Kubernetes ibm-k8s-controller-config configmap field

proxy-set-headers: "ingress-nginx/custom-headers"

For the custom-headers ConfigMap requirements, see this example.

Customizing the response header

To add header information to a client response before sending it to the client, use the following annotation.

nginx.ingress.kubernetes.io/configuration-snippet: |
    more_set_headers "Request-Id: $req_id";

Adding path definitions to external services

To add path definitions to external services, such as services hosted in IBM Cloud, configure a proxy to external services in a location snippet. Or, replace the proxy with a permanent redirect to external services.

Redirecting insecure requests

By default, insecure HTTP client requests redirect to HTTPS. To disable this setting, use the following field and annotation.

• ibm-k8s-controller-config ConfigMap field

  ssl-redirect: "false"
  

• Ingress resource annotation:

  nginx.ingress.kubernetes.io/ssl-redirect: "false"
  

Enabling and disabling HTTP Strict Transport Security

Set the browser to access the domain only by using HTTPS. This option is enabled by default.

• To add max age and subdomain granularity, see this NGINX blog.
• To disable, set the ibm-k8s-controller-config configmap field.

  hsts: false
  

Setting a maximum number of keepalive requests

To set the maximum number of requests that can be served through one keepalive connection, use the following Kubernetes ibm-k8s-controller-config configmap field.

keep-alive-requests: 100

The default value for keep-alive-requests in Kubernetes Ingress is 100, which is much less than the default value of 4096 in IBM Cloud Kubernetes Service Ingress. If you migrated your Ingress setup from IBM Cloud Kubernetes Service Ingress to Kubernetes Ingress, you might need to change keep-alive-requests to pass existing performance tests.

Setting a maximum keepalive request timeout

To set the maximum time that a keepalive connection stays open between the client and the ALB proxy server, use the following Kubernetes ibm-k8s-controller-config configmap field.

keep-alive: 60

Setting a maximum number of large client header buffers

To set the maximum number and size of buffers that read large client request headers, use the following Kubernetes ibm-k8s-controller-config configmap field.

large-client-header-buffers: 4 8k

Modifying how the ALB matches the request URI

To modify the way the ALB matches the request URI against the app path, use the following Kubernetes Ingress resource annotation.

nginx.ingress.kubernetes.io/use-regex: "true"

For more info, see this blog.

Adding custom location block configurations

To add a custom location block configuration for a service, use the following Kubernetes Ingress resource annotation.

nginx.ingress.kubernetes.io/configuration-snippet: |
    more_set_headers "Request-Id: $req_id";

Configuring mutual authentication

To configure mutual authentication for the ALB, use the following Kubernetes Ingress resource annotations. Note that mutual authentication can't be applied to custom ports and must be applied to the HTTPS port.

nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
nginx.ingress.kubernetes.io/auth-tls-secret: "default/ca-secret"
nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
nginx.ingress.kubernetes.io/auth-tls-error-page: "http://www.mysite.com/error-cert.html"
nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true"

Configuring proxy buffer size

To configure the size of the proxy buffer that reads the first part of the response, use the following Kubernetes Ingress resource annotation.

nginx.ingress.kubernetes.io/proxy-buffer-size: "8k"

Configuring proxy buffer numbers

To configure the number of proxy buffers for the ALB, use the following Kubernetes Ingress resource annotation.

nginx.ingress.kubernetes.io/proxy-buffers-number: "4"

Configuring busy proxy buffer size

To configure the size of proxy buffers that can be busy, use a location snippet. For more info, see the NGINX docs.

Configuring when an ALB can pass a request

To set when the ALB can pass a request to the next upstream server, use the following Kubernetes Ingress fields.

• Global setting: ibm-k8s-controller-config ConfigMap fields:

  retry-non-idempotent: true
  proxy-next-upstream: error timeout http_500
  

• Per-resource setting: Ingress resource annotations:

  nginx.ingress.kubernetes.io/proxy-next-upstream: http_500
  nginx.ingress.kubernetes.io/proxy-next-upstream-timeout: 50
  nginx.ingress.kubernetes.io/proxy-next-upstream-tries: 3
  

Rate limiting

To limit the request processing rate and number of connections per a defined key for services, use the Ingress resource annotations for rate limiting.

Removing the response header

You can remove header information that is included in the client response from the back-end end app before the response is sent to the client. Configure the response header removal in a location snippet, or use the proxy_hide_header field as a configuration snippet in the ibm-k8s-controller-config ConfigMap.

Rewriting paths

To route incoming network traffic on an ALB domain path to a different path that your back-end app listens on, use the following Kubernetes Ingress resource annotation.

nginx.ingress.kubernetes.io/rewrite-target: /newpath

Customizing server block configurations

To add a custom server block configuration, use the following Kubernetes Ingress resource annotation.

nginx.ingress.kubernetes.io/server-snippet: |
    location = /health {
    return 200 'Healthy';
    add_header Content-Type text/plain;
    }

Routing incoming network traffic

To always route incoming network traffic to the same upstream server by using a sticky cookie, use the following Kubernetes Ingress resource annotations.

nginx.ingress.kubernetes.io/affinity: "cookie"
nginx.ingress.kubernetes.io/session-cookie-name: "cookie_name1"
nginx.ingress.kubernetes.io/session-cookie-expires: "172800"
nginx.ingress.kubernetes.io/session-cookie-max-age: "172800"
nginx.ingress.kubernetes.io/configuration-snippet: |
  more_set_headers "Set-Cookie: HttpOnly";

The Kubernetes Ingress controller adds the Secure and HttpOnly attributes to the sticky cookies by default, which can't be changed.

Allowing SSL services support to encrypt traffic

To allow SSL services support to encrypt traffic to your upstream apps that require HTTPS, use the Kubernetes Ingress resource backend protocol annotation and the backend certificate authentication annotations.

nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
nginx.ingress.kubernetes.io/proxy-ssl-secret: app1-ssl-secret
nginx.ingress.kubernetes.io/proxy-ssl-verify-depth: 5
nginx.ingress.kubernetes.io/proxy-ssl-name: proxy-ssl-name=mydomain.com
nginx.ingress.kubernetes.io/proxy-ssl-verify: true

Accessing apps with non-standard TCP ports

To access an app via a non-standard TCP port, follow these steps.

1. Create a tcp-services ConfigMap to specify your TCP port, such as the following example ports. For the requirements of the tcp-services ConfigMap, see this blog.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: tcp-services
     namespace: kube-system
   data:
     9000: "<namespace>/<service>:8080"
   

2. Create the ConfigMap in the kube-system namespace.

   kubectl apply -f tcp-services.yaml -n kube-system
   

3. Specify the tcp-services ConfigMap as a field in the ibm-ingress-deploy-config ConfigMap.

   "tcpServicesConfig":"kube-system/tcp-services"
   

4. Modify each ALB service to add the ports.

Setting a maximum number of upstream keepalive requests

To set the maximum number of requests that can be served through one keepalive connection, use the following Kubernetes ibm-k8s-controller-config ConfigMap field.

upstream-keepalive-requests: 32

Setting the maximum upstream keepalive timeout

To set the maximum time that a keepalive connection stays open between the ALB proxy server and your app's upstream server, use the following Kubernetes ibm-k8s-controller-config configmap field.

upstream-keepalive-timeout: 32

Customizing the ALB deployment

Customize the deployment for ALBs that run the Kubernetes Ingress image by creating an ibm-ingress-deploy-config ConfigMap.

1. Get the names of the services that expose each ALB.

   • Classic clusters:

     kubectl get svc -n kube-system | grep alb
     

   • VPC clusters: In the output, look for a service name that is formatted such as public-crc204dl7w0qf6n6sp7tug.

     kubectl get svc -n kube-system | grep LoadBalancer
     

Customizing the Ingress class

An Ingress class associates a class name with an Ingress controller type. Use the IngressClass resource to customize Ingress classes.

Adding App ID authentication to apps

Enforce authentication for your apps by configuring Ingress with IBM Cloud App ID.

1. Choose an existing or create a new App ID instance.

   An App ID instance can be used in only one namespace in your cluster. If you want to configure App ID for Ingress resources in multiple namespaces, repeat the steps in this section to specify a unique App ID instance for the Ingress resources in each namespace.

   • To use an existing instance, ensure that the service instance name contains only lowercase alphanumeric characters and its length does not exceed 25 characters. To change the name, select Rename service from the more options menu on your service instance details page.
   • To provision a new App ID instance:
     1. Replace the Service name with your own unique name for the service instance. The service instance name must contain only lowercase alphanumeric characters and can not be longer than 25 characters.
     2. Choose the same region that your cluster is deployed in.
     3. Click Create.

2. Add redirect URLs for your app. A redirect URL is the callback endpoint of your app. To prevent phishing attacks, IBM Cloud App ID validates the request URL against the allowlist of redirect URLs.

   1. In the App ID management console, navigate to Manage Authentication.
   2. In the Identity providers tab, make sure that you have an Identity Provider selected. If no Identity Provider is selected, the user will not be authenticated but will be issued an access token for anonymous access to the app.
   3. In the Authentication settings tab, add redirect URLs for your app in the format https://<hostname>/oauth2-<App_ID_service_instance_name>/callback. Note that all letters in the service instance name must specified as lowercase.

   If you use the IBM Cloud App ID logout function, you must append /sign_out to your domain in the format https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out and include this URL in the redirect URLs list. If you want to use a custom logout page, you must set whitelist_domains in the ConfigMap for OAuth2-Proxy. Call the https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out endpoint with the rd query parameter or set the X-Auth-Request-Redirect header with your custom logout page. For more details, see Sign out.

3. Bind the App ID service instance to your cluster. The command creates a service key for the service instance, or you can include the --key option to use existing service key credentials. Be sure to bind the service instance to the same namespace that your Ingress resources exist in. Note that all letters in the service instance name must specified as lowercase.

   ibmcloud ks cluster service bind --cluster <cluster_name_or_ID> --namespace <namespace> --service <App_ID_service_instance_name> [--key <service_instance_key>]
   

   When the service is successfully bound to your cluster, a cluster secret is created that holds the credentials of your service instance. Example CLI output:

   ibmcloud ks cluster service bind --cluster mycluster --namespace mynamespace --service appid1
   Binding service instance to namespace...
   OK
   Namespace:    mynamespace
   Secret name:  binding-<service_instance_name>
   

4. Enable the ALB OAuth Proxy add-on in your cluster. This add-on creates and manages the following Kubernetes resources: an OAuth2-Proxy deployment for your App ID service instance, a secret that contains the configuration of the OAuth2-Proxy deployment, and an Ingress resource that configures ALBs to route incoming requests to the OAuth2-Proxy deployment for your App ID instance. The name of each of these resources begins with oauth2-.

   1. Enable the alb-oauth-proxy add-on.

      ibmcloud ks cluster addon enable alb-oauth-proxy --cluster <cluster_name_or_ID>
      

   2. Verify that the ALB OAuth Proxy add-on has a status of Addon Ready.

      ibmcloud ks cluster addon ls --cluster <cluster_name_or_ID>
      

5. In the Ingress resources for apps where you want to add App ID authentication, make sure that the resource name does not exceed 25 characters in length. Then, add the following annotations to the metadata.annotations section.

   1. Add the following auth-url annotation. This annotation specifies the URL of the OAuth2-Proxy for your App ID instance, which acts as the OIDC Relying Party (RP) for App ID. Note that all letters in the service instance name must be specified as lowercase.

      ...
      annotations:
         nginx.ingress.kubernetes.io/auth-url: https://oauth2-<App_ID_service_instance_name>.<namespace_of_Ingress_resource>.svc.cluster.local/oauth2-<App_ID_service_instance_name>/auth
      ...
      

   2. Sometimes the authentication cookie used by OAuth2-Proxy exceeds 4 KB. Therefore it is split into two parts. The following snippet must be added to ensure that both cookies could be properly updated by OAuth2-Proxy.

      ...
      annotations:
          nginx.ingress.kubernetes.io/configuration-snippet: |
          auth_request_set $_oauth2_<App_ID_service_instance_name>_upstream_1 $upstream_cookie__oauth2_<App_ID_service_instance_name>_1;
          access_by_lua_block {
              if ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 ~= "" then
              ngx.header["Set-Cookie"] = "_oauth2_<App_ID_service_instance_name>_1=" .. ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")
              end
          }
      ...
      

   3. Choose which tokens to send in the Authorization header to your app. For more information about ID and access tokens, see the App ID documentation.

      • To send only the ID Token, add the following annotation:

        ...
        annotations:
            nginx.ingress.kubernetes.io/auth-response-headers: Authorization
        ...
        

      • To send only the Access Token, add the following information to the configuration-snippet annotation. (This extends the snippet from Step 5.2.)

        ...
        annotations:
            nginx.ingress.kubernetes.io/configuration-snippet: |
            auth_request_set $_oauth2_<App_ID_service_instance_name>_upstream_1 $upstream_cookie__oauth2_<App_ID_service_instance_name>_1;
            auth_request_set $access_token $upstream_http_x_auth_request_access_token;
            access_by_lua_block {
                if ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 ~= "" then
                ngx.header["Set-Cookie"] = "_oauth2_<App_ID_service_instance_name>_1=" .. ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")
                end
                if ngx.var.access_token ~= "" then
                ngx.req.set_header("Authorization", "Bearer " .. ngx.var.access_token)
                end
            }
        ...
        

      • To send the Access Token and the ID Token, add the following information to the configuration-snippet annotation. (This extends the snippet from Step 5.2.)

        ...
         annotations:
            nginx.ingress.kubernetes.io/configuration-snippet: |
            auth_request_set $_oauth2_<App_ID_service_instance_name>_upstream_1 $upstream_cookie__oauth2_<App_ID_service_instance_name>_1;
            auth_request_set $access_token $upstream_http_x_auth_request_access_token;
            auth_request_set $id_token $upstream_http_authorization;
            access_by_lua_block {
                if ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 ~= "" then
                ngx.header["Set-Cookie"] = "_oauth2_<App_ID_service_instance_name>_1=" .. ngx.var._oauth2_<App_ID_service_instance_name>_upstream_1 .. ngx.var.auth_cookie:match("(; .*)")
                end
                if ngx.var.id_token ~= "" and ngx.var.access_token ~= "" then
                ngx.req.set_header("Authorization", "Bearer " .. ngx.var.access_token .. " " .. ngx.var.id_token:match("%s*Bearer%s*(.*)"))
                end
            }
        ...
        

   4. Optional: If your app supports the web app strategy in addition to or instead of the API strategy, add the nginx.ingress.kubernetes.io/auth-signin: https://$host/oauth2-<App_ID_service_instance_name>/start?rd=$escaped_request_uri annotation. Note that all letters in the service instance name must be in lowercase.

      • If you specify this annotation, and the authentication for a client fails, the client is redirected to the URL of the OAuth2-Proxy for your App ID instance. This OAuth2-Proxy, which acts as the OIDC Relying Party (RP) for App ID, redirects the client to your App ID login page for authentication.
      • If you don't specify this annotation, a client must authenticate with a valid bearer token. If the authentication for a client fails, the client's request is rejected with a 401 Unauthorized error message.

6. Re-apply your Ingress resources to enforce App ID authentication. After an Ingress resource with the appropriate annotations is re-applied, the ALB OAuth Proxy add-on deploys an OAuth2-Proxy deployment, creates a service for the deployment, and creates a separate Ingress resource to configure routing for the OAuth2-Proxy deployment messages. Do not delete these add-on resources.

   kubectl apply -f <app_ingress_resource>.yaml -n namespace
   

7. Verify that App ID authentication is enforced for your apps.

   • If your apps supports the web app strategy: Access your app's URL in a web browser. If App ID is correctly applied, you are redirected to an App ID authentication log-in page.
   • If your apps supports the API strategy: Specify your Bearer access token in the Authorization header of requests to the apps. To get your access token, see the App ID documentation. If App ID is correctly applied, the request is successfully authenticated and is routed to your app. If you send requests to your apps without an access token in the Authorization header, or if the access token is not accepted by App ID, then the request is rejected.

8. Optional: You can customize the default behavior of the OAuth2-Proxy by creating a Kubernetes ConfigMap.

   1. Create a ConfigMap YAML file that specifies values for the OAuth2-Proxy settings that you want to change.

      apiVersion: v1
      kind: ConfigMap
      metadata:
        name: oauth2-<App_ID_service_instance_name>
        namespace: <ingress_resource_namespace>
      data:
        auth_logging: <true|false>
        # Log all authentication attempts.
        auth_logging_format:
        # Format for authentication logs. For more info, see https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#logging-configuration
        cookie_csrf_expire: "15m"
        # Expiration timeframe for CSRF cookie. Default is "15m".
        cookie_csrf_per_request: <true|false>
        # Enable multiple CSRF cookies per request, making it possible to have parallel requests. Default is "false".
        cookie_domains:
        # A list of optional domains to force cookies to. The longest domain that matches the request’s host is used. If there is no match for the request’s host, the shortest domain is used. Example: sub.domain.com,example.com
        cookie_expire: "168h0m0s"
        # Expiration timeframe for cookies. Default: "168h0m0s".
        cookie_samesite: ""
        # SameSite attribute for cookies. Supported values: "lax", "strict", "none", or "".
        email_domains: ""
        # Authenticate IDs that use the specified email domain. To authenticate IDs that use any email domain, use "*". Default: "". Example: example.com,example2.com
        pass_access_token: <true|false>
        # Pass the OAuth access token to the backend app via the X-Forwarded-Access-Token header.
        request_logging: <true|false>
        # Log all requests to the backend app.
        request_logging_format:
        # Format for request logs. For more info, see https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#request-log-format
        scope:
        # Scope of the OAuth authentication. For more info, see https://oauth.net/2/scope/
        set_authorization_header: <true|false>
        # Set the Authorization Bearer response header when the app responds to the Ingress ALB, such when using the NGINX auth_request mode.
        set_xauthrequest: <true|false>
        # Set X-Auth-Request-User, X-Auth-Request-Email, and X-Auth-Request-Preferred-Username response headers when the app responds to the Ingress ALB, such as when using the NGINX auth_request mode.
        standard_logging: <true|false>
        # Log standard runtime information.
        standard_logging_format:
        # Format for standard logs. For more info, see https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#standard-log-format
        tls_secret_name:
        # The name of a secret that contains the server-side TLS certificate and key to enable TLS between the OAuth2-Proxy and the Ingress ALB. By default, the TLS secret defined in your Ingress resources is used.
        whitelist_domains:
        # Allowed domains for redirection after authentication. Default: "". Example: example.com,*.example2.com For more info, see: https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview#command-line-options
        oidc_extra_audiences:
        # Additional audiences which are allowed to pass verification. 
        cookie_refresh: 
        # Refresh the cookie after this duration. Example: "15m". To use this feature, you must enable "Refresh token" for the AppID instance. For more info, see: /docs/appid?topic=appid-managing-idp&interface=ui#idp-token-lifetime
      

   2. Apply the ConfigMap resource to your add-on. Your changes are applied automatically.

      kubectl apply -f oauth2-<App_ID_service_instance_name>.yaml
      

For the list of changes for each ALB OAuth Proxy add-on version, see the IBM Cloud ALB OAuth Proxy add-on change log.

Preserving the source IP address

By default, the source IP addresses of client requests are not preserved by the Ingress ALB. To preserve source IP addresses, you can enable the PROXY protocol in VPC clusters or change the externalTrafficPolicy in classic clusters.

Configuring SSL protocols and SSL ciphers at the HTTP level

Enable SSL protocols and ciphers at the global HTTP level by editing the ibm-k8s-controller-config ConfigMap.

For example, if you still have legacy clients that require TLS 1.0 or 1.1 support, you must manually enable these TLS versions to override the default setting of TLS 1.2 and TLS 1.3 only.

When you specify the enabled protocols for all hosts, the TLSv1.1 and TLSv1.2 parameters (1.1.13, 1.0.12) work only when OpenSSL 1.0.1 or higher is used. The TLSv1.3 parameter (1.13.0) works only when OpenSSL 1.1.1 built with TLSv1.3 support is used.

To edit the ConfigMap to enable SSL protocols and ciphers:

1. Edit the configuration file for the ibm-k8s-controller-config ConfigMap resource.

   kubectl edit cm ibm-k8s-controller-config -n kube-system
   

2. Add the SSL protocols and ciphers. Format ciphers according to the OpenSSL library cipher list format.

   apiVersion: v1
   data:
     ssl-protocols: "TLSv1 TLSv1.1 TLSv1.2 TLSv1.3"
     ssl-ciphers: "HIGH:!aNULL:!MD5:!CAMELLIA:!AESCCM:!ECDH+CHACHA20"
   kind: ConfigMap
   metadata:
     name: ibm-k8s-controller-config
     namespace: kube-system
   

3. Save the configuration file.

4. Verify that the ConfigMap changes were applied. The changes are applied to your ALBs automatically.

   kubectl get cm ibm-k8s-controller-config -n kube-system -o yaml
   

Sending your custom certificate to legacy clients

If you have legacy devices that don't support Server Name Indication (SNI) and you use a custom TLS certificate in your Ingress resources, you must edit the ALB's server settings to use your custom TLS certificate and custom TLS secret.

When you create a classic cluster, a Let's Encrypt certificate is generated for the default Ingress secret that IBM provides. If you create a custom secret in your cluster and specify this custom secret for TLS termination in your Ingress resources, the Ingress ALB sends the certificate for your custom secret to the client instead of the default Let's Encrypt certificate. However, if a client does not support SNI, the Ingress ALB defaults to the Let's Encrypt certificate because the default secret is listed in the ALB's default server settings. To send your custom certificate to devices that don't support SNI, complete the following steps to change the ALB's default server settings to your custom secret.

The Let's Encrypt certificates that are generated by default aren't intended for production usage. For production workloads, bring your own custom certificate.

1. Edit the alb-default-server Ingress resource.

   kubectl edit ingress alb-default-server -n kube-system
   

2. In the spec.tls section, change the value of the hosts.secretName setting to the name of your custom secret that contains your custom certificate. Example:

   spec:
       rules:
       ...
       tls:
       - hosts:
       - invalid.mycluster-<hash>-0000.us-south.containers.appdomain.cloud
       secretName: <custom_secret_name>
   

3. Save the resource file.

4. Verify that the resource now points to your custom secret name. The changes are applied to your ALBs automatically.

   kubectl get ingress alb-default-server -n kube-system -o yaml
   

Tuning ALB performance

To optimize performance of your Ingress ALBs, you can change the default settings according to your needs.