將伺服器埠新增至主機標頭

若要在請求轉送到您的後端應用程式之前，將伺服器連接埠加入客戶端請求，請在 伺服器片段註解中配置外部服務的代理，或作為 ibm-k8s-controller-config ConfigMap 欄位。

使用專用 ALB 遞送送入要求

若要使用專用 ALB 將送入要求遞送至應用程式，請在 Ingress 資源 中指定 private-iks-k8s-nginx 類別註釋。 專用 ALB 配置為搭配使用資源與此類別。

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

使用 App ID 鑑別應用程式

設定 Ingress IBM Cloud App ID 來強制執行應用程式的驗證，方法是變更特定的 Kubernetes Ingress 欄位。 如需詳細資訊，請參閱 在應用程式中加入 App ID 身份驗證。

設定用戶端要求內文大小上限

若要設定用戶端可以傳送作為請求一部分的正文的最大大小，請使用下列 Kubernetes Ingress 資源 註釋。

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

啟用及停用用戶端回應資料緩衝

當資料傳送至用戶端時，您可以停用或啟用在 ALB 上儲存回應資料。 此設定預設為停用狀態。 若要啟用，請設定下列 Ingress 資源 註釋。

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

自訂連接及讀取逾時

若要設定 ALB 在後端應用程式被視為無法使用之前等待連接及讀取後端應用程式的時間量，請使用下列 註釋。

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

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

自訂錯誤動作

若要指出 ALB 可針對特定 HTTP 錯誤採取的自訂動作，請設定 custom-http-errors 欄位。

變更預設 HTTP 和 HTTPS 連接埠

若要變更 HTTP (port 80) 和 HTTPS (port 443) 網路流量的預設連接埠，請利用下列 Kubernetes Ingress ibm-ingress-deploy-config ConfigMap 欄位 修改每個 ALB 服務。

欄位設定範例。

httpPort=8080
httpsPort=8443

自訂要求標頭

若要在將客戶端請求轉發至後端應用程式之前，為該請求新增標頭資訊，請使用以下 Kubernetes ibm-k8s-controller-config configmap 欄位

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

如需 custom-headers ConfigMap 需求，請參閱 此範例。

自訂回應標頭

若要將標頭資訊新增至用戶端回應，然後再將它傳送至用戶端，請使用下列 註釋。

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

為外部服務新增路徑定義

若要新增外部服務的路徑定義，例如 IBM Cloud 中託管的服務，請在 位置片段中設定外部服務的代理。 或者，將 Proxy 取代為 永久重新導向至外部服務。

重新導向不安全的要求

預設情況下，不安全的 HTTP 客戶端要求會重定向到 HTTPS。 若要停用此設定，請使用下列欄位及註釋。

• ibm-k8s-controller-config ConfigMap 欄位

  ssl-redirect: "false"
  

• Ingress 資源 註釋:

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

啟用和停用 HTTP Strict Transport Security

將瀏覽器設為僅使用 HTTPS 來存取網域。 預設會啟用此選項。

• 若要新增最大年齡及子網域粒度，請參閱 此 NGINX 網誌。
• 若要停用，請設定 ibm-k8s-controller-config configmap 欄位。

  hsts: false
  

設定保留作用中要求數目上限

若要設定透過一個 keepalive 連線提供服務的最大要求數目，請使用下列 Kubernetes ibm-k8s-controller-config configmap 欄位。

keep-alive-requests: 100

Kubernetes Ingress 中 keep-alive-requests 的預設值是 100，遠低於 IBM Cloud Kubernetes Service Ingress 中 4096 的預設值。 如果您將 Ingress 設定從 IBM Cloud Kubernetes Service 移轉到 Kubernetes Ingress，您可能需要變更 keep-alive-requests 才能通過現有的效能測試。

設定保留作用中要求逾時上限

若要設定用戶端與 ALB 代理伺服器之間保持連線開啟的最長時間，請使用下列 Kubernetes ibm-k8s-controller-config configmap 欄位。

keep-alive: 60

設定大型用戶端標頭緩衝區數目上限

若要設定讀取大型用戶端要求標頭的緩衝區最大數量和大小，請使用下列 Kubernetes ibm-k8s-controller-config configmap 欄位。

large-client-header-buffers: 4 8k

修改 ALB 符合要求 URI 的方式

若要修改 ALB 與應用程式路徑匹配請求 URI 的方式，請使用下列 Kubernetes Ingress 資源 註釋。

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

如需相關資訊，請參閱 此部落格。

新增自訂位置區塊配置

若要為服務新增自訂位置區塊組態，請使用下列 Kubernetes Ingress 資源 註解。

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

配置交互鑑別

要為 ALB 設定相互驗證，請使用下列 Kubernetes Ingress 資源 註解。 請注意，相互認證無法套用到自訂連接埠，必須套用到 HTTPS 連接埠。

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"

配置 Proxy 緩衝區大小

若要設定讀取回應第一部分的代理緩衝區大小，請使用下列 Kubernetes Ingress 資源 註解。

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

配置 Proxy 緩衝區號碼

若要設定 ALB 的代理緩衝區數量，請使用下列 Kubernetes Ingress 資源 註釋。

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

配置忙碌 Proxy 緩衝區大小

如果要配置可能忙碌的 Proxy 緩衝區大小，請使用 位置 Snippet。 如需詳細資訊，請參閱 NGINX docs。

配置 ALB 何時可以傳遞要求

要設定 ALB 何時可以將請求傳遞到下一個上游伺服器，請使用下列 Kubernetes Ingress 欄位。

• 廣域設定: ibm-k8s-controller-config ConfigMap 欄位:

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

• 每個資源設定 :Ingress 資源 註釋:

  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
  

速率限制

若要針對服務的已定義金鑰限制要求處理速率及連線數，請使用 Ingress 資源 註釋來限制速率。

移除回應標頭

您可以在將回應傳送給客戶端之前，從後端應用程式中移除包含在客戶端回應中的標頭資訊。 在 位置片段中設定移除回應標頭，或使用 proxy_hide_header 欄位作為 ibm-k8s-controller-config ConfigMap 中的 設定片段。

重新編寫路徑

要將 ALB 網域路徑上的傳入網路流量路由到後端應用程式監聽的不同路徑，請使用下列 Kubernetes Ingress 資源 註釋。

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

自訂伺服器區塊配置

若要新增自訂伺服器區塊組態，請使用下列 Kubernetes Ingress 資源 註釋。

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

遞送送入的網路資料流量

若要始終透過使用粘性 cookie 將傳入的網路流量路由至同一個上游伺服器，請使用下列 Kubernetes Ingress 資源 註解。

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";

Kubernetes Ingress 控制器預設會將 Secure 和 HttpOnly 屬性加入黏性 cookies，無法變更。

允許 SSL 服務支援加密流量

若要允許 SSL 服務支援為您需要 HTTPS 的上游應用程式加密流量，請使用 Kubernetes Ingress 資源後端通訊協定註解和 後端證書驗證註解。

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

使用非標準 TCP 連接埠存取應用程式

若要透過非標準 TCP 連接埠存取應用程式，請遵循下列步驟。

1. 建立 tcp-services ConfigMap，指定您的 TCP 連接埠，例如以下範例的連接埠。 有關 tcp-services ConfigMap, 的要求，請參閱 此部落格。

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

2. 在 kube-system 名稱空間中建立 ConfigMap。

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

3. 指定 tcp-services ConfigMap 作為 ibm-ingress-deploy-config ConfigMap 中的欄位。

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

4. 修改每一個 ALB 服務 以新增埠。

設定上游保留作用中要求的數目上限

若要設定可透過一個 keepalive 連線提供服務的最大要求數目，請使用下列 Kubernetes ibm-k8s-controller-config ConfigMap 欄位。

upstream-keepalive-requests: 32

設定上游保留作用中逾時上限

若要設定 ALB 代理伺服器與您的應用程式上游伺服器之間保持連線開啟的最長時間，請使用下列 Kubernetes ibm-k8s-controller-config configmap 欄位。

upstream-keepalive-timeout: 32

自訂 ALB 部署

透過建立 ibm-ingress-deploy-config ConfigMap，為執行 Kubernetes Ingress 映像的 ALB 自訂部署。

1. 取得公開每一個 ALB 的服務名稱。

   • 標準叢集：

       kubectl get svc -n kube-system | grep alb
       ```
   * VPC 叢集: 在輸出中，尋找已格式化的服務名稱，例如 `public-crc204dl7w0qf6n6sp7tug`。
   
   ```sh {: pre}
       kubectl get svc -n kube-system | grep LoadBalancer
       ```
   

自訂 Ingress 類別

Ingress 類別會將類別名稱與 Ingress 控制器類型相關聯。 使用 IngressClass 資源來自訂 Ingress 類別。

將 App ID 鑑別新增至應用程式

透過設定 Ingress 與 IBM Cloud App ID.

1. 選擇現有實例，或建立新的 App ID 實例。

   一個 App ID 實例只能用於群集中的一個命名空間。 如果要為多個命名空間中的 Ingress 資源設定 App ID，請重複本節中的步驟，為每個命名空間中的 Ingress 資源指定唯一的 App ID 實例。

   • 若要使用現有實例，請確保服務實例名稱僅包含 小寫 英數字元，且其長度不超過 25 個字元。 若要變更名稱，請從服務實例詳細資料頁面上的其他選項功能表中選取 重新命名服務。
   • 若要佈建新的 App ID 實例，請執行下列動作：
     1. 請將「服務名稱」替換為您為該服務執行個體所設定的專屬名稱。 服務實例名稱必須只包含小寫字母數字字符，且不能超過 25 個字元。
     2. 選擇叢集部署所在的相同地區。
     3. 按一下建立。

2. 新增應用程式的重新導向 URL。 重新導向 URL 是應用程式的回呼端點。 為防止網路釣魚攻擊，IBM Cloud App ID 會將請求 URL 與重定向 URL 的白名單進行比對驗證。

   1. 在 App ID 管理主控台，導覽至管理鑑別。
   2. 在身分提供者標籤中，確保已選取身分提供者。 若未選取任何身分識別提供者，系統將不會對使用者進行驗證，但會發放一個存取憑證，供使用者以匿名方式存取該應用程式。
   3. 在「驗證設定」分頁中，請以 https://<hostname>/oauth2-<App_ID_service_instance_name>/callback 這種格式為您的應用程式新增重定向網址。 請注意，服務實例名稱中的所有字母都必須指定為小寫。

   如果您使用 IBM Cloud App ID 登出功能，則必須以 https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out 的格式將 /sign_out 附加到您的網域名稱，並將此 URL 包含在重定向 URL 清單中。 如果要使用自訂登出頁面，必須在 ConfigMap 中設定 whitelist_domains，以便 OAuth2-Proxy。 使用 rd 查詢參數呼叫 https://<hostname>/oauth2-<App_ID_service_instance_name>/sign_out 端點，或使用自訂登出頁面設定 X-Auth-Request-Redirect 標頭。 如需詳細資料，請參閱 登出。

3. 將 App ID 服務實例連結至叢集。 此指令會為服務實例建立一個服務金鑰；您也可以加入 --key 選項，以使用現有的服務金鑰憑證。 請務必將服務實例連結至 Ingress 資源所在的相同名稱空間。 請注意，服務實例名稱中的所有字母都必須指定為小寫。

   ibmcloud ks cluster service bind --cluster CLUSTER_NAME_OR_ID --namespace NAMESPACE --service APP_ID_SERVICE_INSTANCE_NAME [--key SERVICE_INSTANCE_KEY]
   

   當服務成功綁定至您的叢集時，系統會建立一個叢集機密，用以儲存您的服務執行個體的憑證。 CLI 輸出範例：

   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. 在群集中啟用 ALB OAuth Proxy 附加元件。 此附加元件會建立並管理下列 Kubernetes 資源：一個適用於 App ID 服務實體的 OAuth2-Proxy 部署、一個包含 OAuth2-Proxy 部署設定的秘密，以及一個可設定 ALB 以將傳入的要求路由到 App ID 實體的 OAuth2-Proxy 部署的 Ingress 資源。 每一個資源的名稱都以 oauth2- 開頭。

   1. 啟用 alb-oauth-proxy 附加程式。

       ibmcloud ks cluster addon enable alb-oauth-proxy --cluster CLUSTER_NAME_OR_ID
       ```
   2. 確認 ALB OAuth Proxy 附加元件的狀態為 `Addon Ready`。
   ```sh {: pre}
       ibmcloud ks cluster addon ls --cluster CLUSTER_NAME_OR_ID
       ```
   

5. 在您要新增 App ID 鑑別之應用程式的 Ingress 資源中，請確定資源名稱長度不超過 25 個字元。 然後，將下列註釋新增至 metadata.annotations 區段。

   1. 新增下列 auth-url 註釋。 此註解指定 URL 的 OAuth2-Proxy 用於您的 App ID 範例，它是 App ID 的 OIDC 信賴憑證者 (RP)。 請注意，服務實例名稱中的所有字母都必須指定為小寫。

       ...
       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. 有時 `OAuth2-Proxy` 使用的鑑別 Cookie 超過 4 KB。 因此，它分成兩個部分。 必須新增下列 Snippet，以確保 `OAuth2-Proxy` 可以適當地更新這兩個 Cookie。
   ```yaml {: codeblock}
       ...
       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. 選擇要在 `Authorization` 標頭中傳送至應用程式的記號。 如需 ID 及存取記號的相關資訊，請參閱 [App ID 文件](/docs/appid?topic=appid-tokens){: external}。
       * 若只要傳送 `ID Token`，請新增下列註釋:
   
           ```yaml {: codeblock}
           ...
           annotations:
               nginx.ingress.kubernetes.io/auth-response-headers: Authorization
           ...
           ```
       * 若只要傳送 `Access Token`，請將下列資訊新增至 `configuration-snippet` 註釋。 (這會從步驟 5.2延伸 Snippet。)
   
           ```yaml {: codeblock}
           ...
           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
               }
           ...
           ```
       * 若要傳送 `Access Token` 和 `ID Token`，請將下列資訊新增至 `configuration-snippet` 註釋。 (這會從步驟 5.2延伸 Snippet。)
           ```yaml {: codeblock}
           ...
            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. 選用項目: 如果您的應用程式除了 [API 策略](/docs/appid?topic=appid-key-concepts#term-api-strategy) 之外還支援 [Web 應用程式策略](/docs/appid?topic=appid-key-concepts#term-web-strategy)，請新增 `nginx.ingress.kubernetes.io/auth-signin: https://$host/oauth2-<App_ID_service_instance_name>/start?rd=$escaped_request_uri` 註釋。 請注意，服務實例名稱中的所有字母都必須是小寫。
       * 如果您指定此註解，而用戶端認證失敗，則該用戶端會被重定向到您 App ID 範例的 OAuth2-Proxy 的 URL。 這個 OAuth2-Proxy，作為 App ID 的 OIDC 信賴方 (RP)，會將用戶端重定向到您的 App ID 登入頁面進行驗證。
       * 如果您未指定此註釋，則用戶端必須使用有效的載送記號進行鑑別。 如果用戶端鑑別失敗，則會拒絕用戶端的要求，並顯示 `401 Unauthorized` 錯誤訊息。
   
   

6. 重新套用 Ingress 資源以施行 App ID 鑑別。 在重新套用具有適當註解的 Ingress 資源後，ALB OAuth Proxy 附加元件會部署 OAuth2-Proxy 部署、為部署建立服務，並建立單獨的 Ingress 資源，以設定 OAuth2-Proxy 部署訊息的路由。 請勿刪除這些附加程式資源。

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

7. 驗證已對您的應用程式施行 App ID 鑑別。

   • 如果您的應用程式支援 Web 應用程式策略：在網頁瀏覽器中存取您的應用程式 URL。 如果 App ID 應用正確，您會被重定向到 App ID 驗證登入頁面。
   • 如果您的應用程式支援 API 策略: 在應用程式要求的 Authorization 標頭中指定 Bearer 存取記號。 若要取得存取記號，請參閱 App ID 文件。 如果已正確套用 App ID，則會順利鑑別要求並將其遞送至您的應用程式。 如果您將要求傳送至應用程式，但 Authorization 標頭中沒有存取記號，或 App ID未接受存取記號，則會拒絕要求。

8. 可選：如果您在群集上使用網路政策或其他防火牆解決方案來限制外送流量，則必須確定允許從群集存取 AppID's 公共服務。 若要取得此服務的 IP 位址範圍，請透過 客戶支援 提交申請。

9. 選用項目: 您可以透過建立 Kubernetes ConfigMap來自訂 OAuth2-Proxy 的預設行為。

   1. 建立 ConfigMap YAML 檔案，以指定您要變更的 OAuth2-Proxy 設定值。

       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 time 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 time 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. 將 ConfigMap 資源套用至您的附加程式。 您的變更會自動套用。
   ```sh {: pre}
       kubectl apply -f oauth2-<App_ID_service_instance_name>.yaml
       ```
   

如需各 ALB OAuth Proxy 附加元件版本的變更清單，請參閱 IBM Cloud ALB OAuth Proxy 附加元件變更記錄。

保留來源 IP 位址

依預設，Ingress ALB 不會保留用戶端要求的來源 IP 位址。 若要保留來源 IP 位址，您可以啟用 VPC 叢集中的 PROXY 通訊協定 或 在標準叢集中變更 externalTrafficPolicy。

配置 HTTP 層次的 SSL 通訊協定及 SSL 密碼

請透過編輯 ibm-k8s-controller-config ConfigMap 檔案，在全域 HTTP 層級啟用 SSL 協定與加密套件。

例如，如果您仍有需要 TLS 1.0 或 1.1 支援的傳統用戶端，則必須手動啟用這些 TLS 版本，以覆蓋 TLS 1.2 和 TLS 1.3 僅限的預設設定。

當您指定所有主機的已啟用通訊協定時，只有在使用 OpenSSL 1.0.1 或更新版本時，TLSv1.1 及 TLSv1.2 參數（1.1.13、1.0.12）才有作用。 只有在使用以 TLSv1.3 支援所建置的 OpenSSL 1.1.1 時，TLSv1.3 參數 (1.13.0) 才有作用。

若要編輯 ConfigMap，以啟用 SSL 通訊協定及密碼，請執行下列動作：

1. 編輯 ibm-k8s-controller-config ConfigMap 資源的設定檔。

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

2. 新增 SSL 通訊協定及密碼。 根據 OpenSSL 函式庫的密碼清單格式來格式化密碼。

   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. 儲存配置檔。

4. 驗證已套用 ConfigMap 變更。 變更會自動套用至 ALB。

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

將自訂憑證傳送至舊式用戶端

如果您擁有不支援伺服器名稱指示 (SNI) 的舊版裝置，且使用 在您的 Ingress 資源中設定自訂的 TLS 憑證，則必須編輯 ALB 的伺服器設定，以使用您的自訂 TLS 憑證及自訂 TLS 機密。

當您建立標準叢集時，會針對 IBM 所提供的預設 Ingress 密碼產生 Let's Encrypt 憑證。 如果您在叢集裡建立自訂密碼，並在 Ingress 資源中指定此自訂密碼來進行 TLS 終止，則 Ingress ALB 會將自訂密碼的憑證傳送至用戶端，而非預設 Let's Encrypt 憑證。 不過，如果用戶端不支援 SNI，則 Ingress ALB 預設為 Let's Encrypt 憑證，因為預設密碼會列在 ALB 的預設伺服器設定中。 若要將您的自訂憑證傳送至不支援 SNI 的裝置，請依照以下步驟將 ALB 的預設伺服器設定變更為您的自訂密鑰。

依預設產生的 Let 's Encrypt 憑證並不預期用於正式作業用途。 若為正式作業工作負載，請自帶自訂憑證。

1. 編輯 alb-default-server Ingress 資源。

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

2. 在 spec.tls 區段中，將 hosts.secretName 設定的值變更為包含您自訂憑證之自訂密碼的名稱。 範例：

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

3. 儲存資源檔。

4. 驗證資源現在指向您的自訂密碼名稱。 變更會自動套用至 ALB。

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

微調連線處理

client-header-timeout、client-body-timeout 和 keep-alive 設定是重要的設定，可決定用戶端、Ingress 控制器和後端伺服器之間的連線保持作用中的時間長短。 這些超時在最佳化請求處理中扮演重要的角色，尤其是在處理長時間的用戶端連線、後端伺服器的延遲回應，以及保護寶貴的資源不被不必要地佔用時。

client-header-timeout 定義伺服器等待完整用戶端標頭的最長時間。 同樣地，client-body-timeout 表示伺服器等待客戶端傳送要求正文的時間長度。 這兩個逾時都必須與 keep-alive 參數一致，該參數會規範伺服器在等待進一步請求時保持連線開啟的時間。 如果這些超時與 keep-alive 設定不匹配，NGINX 將會終止連線，這可能會導致意外的用戶端行為或請求失敗。

您可以在 kube-system 命名空間中的 ibm-k8s-controller-config ConfigMap 內設定這些參數。

apiVersion: v1
kind: ConfigMap
metadata:
  name: ibm-k8s-controller-config
  namespace: kube-system
data:
  ...
  client-body-timeout: "100"
  client-header-timeout: "100"
  keep-alive: "100"

如需詳細資訊，請參閱 client-header-timeout, client-body-timeout 和 keep-aliveNginx 選項。

調整 ALB 效能

若要將 Ingress ALB 的效能最佳化，您可以根據需求來變更預設值。