호스트 헤더에 서버 포트 추가

요청이 백엔드 앱으로 전달되기 전에 클라이언트 요청에 서버 포트를 추가하려면 서버 스니펫 주석 또는 ibm-k8s-controller-config ConfigMap 필드에서 외부 서비스에 대한 프록시를 구성합니다.

사설 ALB를 사용하여 수신 요청 라우팅

사설 ALB를 사용하여 앱으로 수신 요청을 라우팅하려면 Ingress 리소스 에서 private-iks-k8s-nginx 클래스 어노테이션을 지정하십시오. 사설 ALB는 이 클래스와 함께 자원을 사용하도록 구성됩니다.

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

App ID 을 사용하여 앱 인증

로 인그레스 구성 IBM Cloud App ID 로 구성하여 특정 Kubernetes 인그레스 필드를 변경하여 앱에 인증을 적용합니다. 자세한 내용은 앱에 App ID 인증 추가하기를 참조하세요.

최대 클라이언트 요청 본문 크기 설정

클라이언트가 요청의 일부로 보낼 수 있는 본문의 최대 크기를 설정하려면 다음 Kubernetes 인그레스 리소스 어노테이션을 사용하세요.

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

오류 조치 사용자 정의

특정 HTTP 오류에 대해 ALB가 수행할 수 있는 사용자 지정 작업을 표시하려면 custom-http-errors 필드를 설정합니다.

HTTP 와 HTTPS 기본 포트의 변경

HTTP (포트 80) 및 HTTPS (포트 443) 네트워크 트래픽의 기본 포트를 변경하려면 다음 Kubernetes 인그레스 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 에서 호스팅되는 서비스와 같은 외부 서비스에 경로 정의를 추가하려면 위치 스니펫에서 외부 서비스에 대한 프록시를 구성합니다. 또는 프록시를 외부 서비스로 영구 경로 재지정으로 대체하십시오.

비보안 요청 경로 재지정

기본적으로 안전하지 않은 HTTP 클라이언트 요청은 HTTPS 으로 리디렉션됩니다. 이 설정을 사용하지 않으려면 다음 필드 및 어노테이션을 사용하십시오.

• ibm-k8s-controller-config ConfigMap 필드

  ssl-redirect: "false"
  

• Ingress 자원 어노테이션:

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

HTTP 활성화 및 비활성화 엄격한 전송 보안

HTTPS를 통해서만 도메인에 액세스하도록 브라우저를 설정합니다. 이 옵션은 기본적으로 사용으로 설정됩니다.

• 최대 유효 기간 및 하위 도메인 단위 설정을 추가하려면 NGINX 블로그를 참조하세요.
• 비활성화하려면 ibm-k8s-controller-config 구성 맵 필드를 설정하십시오.

  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 의 기본값보다 훨씬 작습니다. IBM Cloud Kubernetes Service Ingress에서 Kubernetes Ingress로 Ingress 설정을 마이그레이션한 경우, 기존 Performance Test를 통과하려면 keep-alive-requests를 변경해야 합니다.

최대 활성 유지 (keepalive) 요청 제한시간 설정

클라이언트와 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 인그레스 리소스 어노테이션을 사용하세요.

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

자세한 정보는 이 블로그를 참조하십시오.

사용자 정의 위치 블록 구성 추가

서비스에 대한 사용자 지정 위치 블록 구성을 추가하려면 다음 Kubernetes 인그레스 리소스 어노테이션을 사용하세요.

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

상호 인증 구성

ALB에 대한 상호 인증을 구성하려면 다음 Kubernetes 인그레스 리소스 어노테이션을 사용하세요. 상호 인증은 사용자 정의 포트에 적용할 수 없으며 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"

프록시 버퍼 크기 구성

응답의 첫 부분을 읽는 프록시 버퍼의 크기를 구성하려면 다음 Kubernetes 인그레스 리소스 어노테이션을 사용하세요.

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

프록시 버퍼 번호 구성

ALB의 프록시 버퍼 수를 구성하려면 다음 Kubernetes 인그레스 리소스 어노테이션을 사용하세요.

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

사용 중인 프록시 버퍼 크기 구성

사용 중일 수 있는 프록시 버퍼의 크기를 구성하려면 위치 스니펫을 사용하십시오. 자세한 내용은 NGINX 문서를 참조하십시오.

ALB가 요청을 전달할 수 있는 경우 구성

ALB가 다음 업스트림 서버로 요청을 전달할 수 있는 시기를 설정하려면 다음 Kubernetes 인그레스 필드를 사용하세요.

• 글로벌 설정: ibm-k8s-controller-config ConfigMap fields:

  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 리소스 어노테이션을 사용하여 속도 제한을 수행하십시오.

응답 헤더 제거

클라이언트 응답에 포함된 헤더 정보는 응답이 클라이언트로 전송되기 전에 백엔드 애플리케이션에서 제거할 수 있습니다. 위치 코드조각에서 응답 헤더 제거를 구성하거나 ibm-k8s-controller-config ConfigMap 에서 proxy_hide_header 필드를 구성 코드 조각으로 사용하세요.

경로 재작성

ALB 도메인 경로에서 들어오는 네트워크 트래픽을 백엔드 앱이 수신하는 다른 경로로 라우팅하려면 다음 Kubernetes 인그레스 리소스 어노테이션을 사용하세요.

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

서버 블록 구성 사용자 정의

사용자 지정 서버 블록 구성을 추가하려면 다음 Kubernetes 인그레스 리소스 어노테이션을 사용하세요.

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

수신 네트워크 트래픽 라우팅

스티키 쿠키를 사용하여 수신 네트워크 트래픽을 항상 동일한 업스트림 서버로 라우팅하려면 다음 Kubernetes 인그레스 리소스 어노테이션을 사용하세요.

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 속성을 추가하므로 변경할 수 없습니다.

SSL 서비스 지원에서 트래픽 암호화 허용

SSL 서비스 지원이 HTTPS 이 필요한 업스트림 앱의 트래픽을 암호화하도록 허용하려면 Kubernetes 인그레스 리소스 백엔드 프로토콜 어노테이션과 백엔드 인증서 인증 어노테이션을 사용하세요.

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 configmapibm-ingress-deploy-config에서 configmap을 필드로 지정하십시오.

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

4. 각 ALB 서비스를 수정하여 포트를 추가하십시오.

최대 업스트림 Keepalive 요청 수 설정

하나의 킵얼라이브 연결을 통해 제공할 수 있는 최대 요청 수를 설정하려면 다음 Kubernetes ibm-k8s-controller-config ConfigMap 필드를 사용하세요.

upstream-keepalive-requests: 32

최대 업스트림 Keepalive 제한시간 설정

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. ID 제공자 탭에서 ID 제공자가 선택되었는지 확인하십시오. 신원 제공자가 선택되지 않은 경우, 사용자는 인증되지 않지만 앱에 익명으로 액세스할 수 있는 액세스 토큰이 발급됩니다.
   3. 인증 설정 탭에서 앱의 경로 재지정 URL을 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 에서 OAuth2-Proxy 을 whitelist_domains 으로 설정해야 합니다. 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 추가 기능을 사용으로 설정하십시오. 이 추가 기능은 App ID 서비스 인스턴스에 대한 OAuth2-Proxy 배치, OAuth2-Proxy 배치의 구성이 포함된 시크릿 및 수신 요청을 App ID 인스턴스에 대한 OAuth2-Proxy 배치로 라우팅하기 위한 ALB를 구성하는 Ingress 리소스와 같은 Kubernetes 리소스를 작성하고 관리합니다. 이러한 리소스의 이름은 각각 oauth2-로 시작됩니다.

   1. alb-oauth-proxy 추가 기능을 사용으로 설정하십시오.

       ibmcloud ks cluster addon enable alb-oauth-proxy --cluster CLUSTER_NAME_OR_ID
       ```
   2. ALB OAuth 프록시 추가 기능에 `Addon Ready` 상태가 있는지 확인하십시오.
   ```sh {: pre}
       ibmcloud ks cluster addon ls --cluster CLUSTER_NAME_OR_ID
       ```
   

5. App ID 인증을 추가하려는 앱의 Ingress 리소스에서 리소스 이름의 길이가 25자를 초과하지 않는지 확인하십시오. 그런 다음 metadata.annotations 섹션에 다음 어노테이션을 추가하십시오.

   1. 다음 auth-url 어노테이션을 추가하십시오. 이 어노테이션은 App ID에 대한 OIDC 신뢰 당사자(RP)로 작동하는 App ID 인스턴스에 대한 OAuth2-Proxy의 URL을 지정합니다. 서비스 인스턴스 이름의 문자는 모두 소문자로 지정해야 합니다.

       ...
       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` 에서 사용하는 인증 쿠키가 4KB를 초과하는 경우가 있습니다. 따라서 두 파트로 분할됩니다. 두 쿠키가 모두 `OAuth2-Proxy` 에 의해 올바르게 업데이트될 수 있도록 다음 스니펫을 추가해야 합니다.
   ```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단계의 스니펫을 확장합니다.)
   
           ```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단계의 스니펫을 확장합니다.)
           ```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)과 함께 또는 대신 [웹 앱 전략](/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로 경로 재지정됩니다. App ID에 대한 OIDC 신뢰 당사자(RP)로 작동하는 이 OAuth2-Proxy는 인증을 위해 클라이언트를 App ID 로그인 페이지로 경로 재지정합니다.
       * 이 어노테이션을 지정하지 않으면 클라이언트는 올바른 베어러 토큰으로 인증해야 합니다. 클라이언트에 대한 인증에 실패하는 경우 `401 Unauthorized` 오류 메시지와 함께 클라이언트의 요청이 거부됩니다.
   
   

6. Ingress 리소스를 다시 적용하여 App ID 인증을 강제 수행하십시오. 적절한 어노테이션이 포함된 Ingress 리소스가 다시 적용되면 OAuth2-Proxy 배치 메시지에 대한 라우팅을 구성하기 위해 ALB OAuth 프록시 추가 기능에서 OAuth2-Proxy 배치를 배치하고, 배치를 위한 서비스를 작성하고, 별도의 Ingress 리소스를 작성합니다. 이러한 추가 기능 리소스를 삭제하지 마십시오.

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

7. App ID 어노테이션이 사용자의 앱에 맞게 적용되었는지 확인하십시오.

   • 앱이 웹 앱 전략을 지원하는 경우: 웹 브라우저에서 앱의 URL에 액세스하십시오. App ID가 올바르게 적용되면 App ID 인증 로그인 페이지로 경로 재지정됩니다.
   • 앱이 API 전략을 지원하는 경우: 앱에 대한 요청의 권한 헤더에 Bearer 액세스 토큰을 지정하십시오. 액세스 토큰을 가져오려면 App ID 문서를 참조하십시오. App ID가 올바르게 적용되면 요청이 인증되고 앱으로 라우트됩니다. 권한 헤더에 액세스 토큰이 없는 상태로 앱에 요청을 보내거나 액세스 토큰이 App ID에 의해 승인되지 않으면, 요청이 거부됩니다.

8. 선택 사항: 클러스터에서 네트워크 정책 또는 다른 방화벽 솔루션을 사용하여 나가는 트래픽을 제한하는 경우, 클러스터에서 AppID's 퍼블릭 서비스에 대한 액세스를 허용해야 합니다. 이 서비스를 위한 IP 주소 범위를 얻으려면 고객 지원을 통해 요청을 제출하세요.

9. 선택사항: Kubernetes ConfigMap을 작성하여 OAuth2-Proxy의 기본 동작을 사용자 정의할 수 있습니다.

   1. 변경할 OAuth2-Proxy 설정에 대한 값을 지정하는 ConfigMap YAML 파일을 작성하십시오.

       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 프록시 애드온 버전의 변경 사항 목록은 IBM Cloud ALB OAuth 프록시 애드온 변경 내역을 참조하십시오.

소스 IP 주소 유지

기본적으로 클라이언트 요청의 소스 IP 주소는 Ingress ALB에서 유지되지 않습니다. 소스 IP 주소를 유지하기 위해 VPC 클러스터에서 PROXY 프로토콜 사용으로 설정하거나 클래식 클러스터의 externalTrafficPolicy를 변경할 수 있습니다.

HTTP 레벨에서 SSL 프로토콜과 SSL 암호 구성

ibm-k8s-controller-config configmap을 편집하여 글로벌 HTTP 레벨에서 SSL 프로토콜 및 암호를 사용으로 설정하십시오.

예를 들어, 여전히 TLS 1.0 또는 1.1 지원이 필요한 레거시 클라이언트가 있는 경우 TLS 1.2 및 TLS 1.3의 기본 설정만 대체하도록 수동으로 이러한 TLS 버전을 사용으로 설정해야 합니다.

모든 호스트에 대해 사용으로 설정된 프로토콜을 지정하는 경우, TLSv1.1 및 TLSv1.2 매개변수(1.1.13, 1.0.12)는 OpenSSL 1.0.1 이상을 사용할 때만 작동합니다. TLSv1.3 매개변수(1.13.0)는 TLSv1.3 지원으로 빌드된 OpenSSL 1.1.1을 사용하는 경우에만 작동합니다.

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(Server Name Indication)를 지원하지 않는 레거시 디바이스가 있고 Ingress 리소스에 있는 사용자 정의 TLS 인증서를 사용하는 경우, 사용자 정의 TLS 인증서 및 사용자 정의 TLS 시크릿을 사용하도록 ALB의 서버 설정을 편집해야 합니다.

클래식 클러스터를 작성하는 경우 Let's Encrypt 인증서는 IBM에서 제공하는 기본 Ingress 시크릿에 대해 생성됩니다. 클러스터에서 사용자 정의 시크릿을 작성하고 Ingress 리소스에서 TLS 종료를 위해 이 사용자 정의 시크릿을 지정하는 경우 Ingress ALB는 기본 Let's Encrypt 인증서 대신 사용자 정의 시크릿의 인증서를 클라이언트에 전송합니다. 그러나 클라이언트가 SNI를 지원하지 않는 경우, 기본 시크릿이 ALB의 기본 서버 설정에 나열되어 있으므로 Ingress ALB는 기본적으로 Let's Encrypt 인증서를 설정합니다. 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 설정은 클라이언트, 인그레스 컨트롤러, 백엔드 서버 간에 연결이 활성 상태로 유지되는 시간을 결정하는 중요한 구성입니다. 이러한 시간 제한은 특히 오래 지속되는 클라이언트 연결, 백엔드 서버의 지연된 응답을 처리하고 귀중한 리소스가 불필요하게 사용되지 않도록 보호할 때 요청 처리를 최적화하는 데 중요한 역할을 합니다.

client-header-timeout 은 서버가 완전한 클라이언트 헤더를 기다리는 최대 시간을 정의합니다. 마찬가지로 client-body-timeout 은 서버가 클라이언트가 요청 본문을 보낼 때까지 기다리는 기간을 나타냅니다. 이 두 시간 제한은 모두 서버가 추가 요청을 기다리는 동안 연결을 열어 두는 시간을 조절하는 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-alive 옵션을 참조하세요 Nginx 문서.

ALB 성능 튜닝

Ingress ALB의 성능을 최적화하기 위해 필요에 따라 기본 설정을 변경할 수 있습니다.