백엔드 서비스에 커스텀 헤더 만들기

커스텀 요청과 응답 헤더를 사용하면 부하 분산기가 HTTP(S) 요청 및 응답에 추가할 수 있는 추가 헤더를 지정할 수 있습니다. 부하 분산기에서 감지된 정보에 따라 헤더에는 다음 정보가 포함될 수 있습니다.

• 클라이언트에 대한 지연 시간
• 클라이언트 IP 주소의 지리적 위치
• TLS 연결 매개변수

커스텀 요청 헤더는 백엔드 서비스에서 지원되고 커스텀 응답 헤더는 백엔드 서비스와 백엔드 버킷에서 지원됩니다.

부하 분산기는 백엔드와 클라이언트 사이에서 프록시하는 모든 HTTP(S) 요청과 응답에 기본적으로 특정 헤더를 추가합니다. 자세한 내용은 대상 프록시를 참조하세요.

시작하기 전에

• 필요한 경우 Google Cloud CLI를 최신 버전으로 업데이트합니다.

  gcloud components update
  

커스텀 헤더 작동 방식

커스텀 헤더는 다음과 같이 작동합니다.

• 부하 분산기가 백엔드에 요청을 전달할 때 요청 헤더를 추가합니다.

  부하 분산기는 상태 점검 프로브가 아닌 클라이언트 요청에만 커스텀 요청 헤더를 추가합니다. 백엔드에 상태 점검 패킷에서 누락된 특정 승인 헤더가 필요하면 상태 점검이 실패할 수 있습니다.

• 부하 분산기는 클라이언트에 응답을 반환하기 전에 응답 헤더를 설정합니다.

커스텀 헤더를 사용 설정하려면 백엔드 서비스나 백엔드 버킷의 속성에 헤더 목록을 지정합니다.

각 헤더를 header-name:header-value 문자열로 지정합니다. 헤더에는 헤더 이름과 헤더 값을 구분하는 콜론이 있어야 합니다.

헤더 이름은 다음 요구사항을 충족해야 합니다.

• 헤더 이름은 유효한 HTTP 헤더 필드 이름 정의여야 합니다(RFC 7230에 따름).
• Host 헤더를 구성할 수 있지만 특정 제한사항이 적용됩니다.
• 헤더 이름은 authority가 아니어야 합니다. Google Cloud에서 예약되는 특별한 키워드입니다. 전역 외부 애플리케이션 부하 분산기와 같은 이러한 Envoy 기반 부하 분산기의 헤더를 수정할 수 없습니다. 대신 예약된 헤더 이름과 겹치지 않도록 다른 커스텀 헤더를 만드는 것이 좋습니다.
• 헤더 이름은 X-User-IP 또는 CDN-Loop가 아니어야 합니다.
• 다음 홉별 헤더에서는 Keep-Alive, Transfer-Encoding, TE, Connection, Trailer, Upgrade, Proxy-Authorization, Proxy-Authenticate를 사용하면 안 됩니다. RFC 2616에 따라 이러한 헤더는 캐시로 저장되지 않거나 대상 프록시로 전파되지 않습니다.
• 헤더 이름은 X-Google, X-Goog-, X-GFE 또는 X-Amz-로 시작되면 안 됩니다.
• 헤더 이름은 추가된 헤더 목록에 두 번 이상 나타나지 않아야 합니다.

헤더 값은 다음 요구사항을 충족해야 합니다.

• 헤더 값은 RFC 7230에 따라 올바른 HTTP 헤더 필드 정의여야 합니다(사용되지 않는 양식은 허용되지 않음).
• 헤더 값은 비워 둘 수 있습니다.
• 헤더 값에는 부하 분산기가 제공하는 값으로 확장되는 중괄호로 묶인 하나 이상의 변수가 포함될 수 있습니다. 헤더 값에 허용되는 변수 목록은 다음 섹션에 있습니다.

gcloud 명령줄 도구에는 요청 헤더를 지정하는 플래그인 --custom-request-header가 있습니다. 이 플래그를 사용할 때는 헤더 이름과 헤더 값을 곧은 작은따옴표(')로 묶어야 합니다.

플래그의 일반적인 형식은 다음과 같습니다.

    --custom-request-header='HEADER_NAME:[HEADER_VALUE]'

다음은 중괄호로 묶인 두 변수 client_region 및 client_city가 있는 헤더 값의 예입니다.

    --custom-request-header='X-Client-Geo-Location:{client_region},{client_city}'

캘리포니아주 마운틴뷰에 있는 클라이언트의 경우 부하 분산기에서 다음과 같은 헤더를 추가합니다.

X-Client-Geo-Location:US,Mountain View

호스트 헤더

전역 외부 애플리케이션 부하 분산기로 커스텀 Host 헤더를 구성할 때는 다음 제한사항이 적용됩니다.

• 기존 Host 요청 헤더를 대체하는 경우 커스텀 Host 요청 헤더만 구성할 수 있습니다.
• URL 맵에서 헤더 작업을 사용하여 커스텀 Host 응답 헤더를 구성할 수 없습니다. 그러나 백엔드 서비스에서 커스텀 Host 응답 헤더를 계속 구성할 수 있습니다.
• 또한 요청 및 응답 헤더 모두에 다음이 적용됩니다.
  • 커스텀 Host 헤더는 추가하거나 삭제할 수 없습니다.
  • 커스텀 Host 헤더에 변수를 사용할 수 없습니다.

헤더 값이 지원되는 변수

커스텀 헤더 값에 다음 변수가 나타날 수 있습니다.

부하 분산기는 값을 확인할 수 없는 경우 변수를 빈 문자열로 확장합니다. 예를 들면 다음과 같습니다.

• IP 주소의 위치를 알 수 없는 경우의 지리적 위치 변수
• TLS를 사용하지 않는 경우의 TLS 매개변수
• 요청에 Origin 헤더가 포함되지 않은 경우의 {origin_request_header}
• 요청 헤더에 포함되었을 때의 {cdn_cache_status} 헤더

지리적 값(리전, 구획, 도시)은 클라이언트 IP 주소를 기반으로 한 추정치입니다. 때때로 Google은 정확성을 향상시키고 지리적 및 정치적 변화를 반영하기 위해 이러한 값을 제공하는 데이터를 업데이트합니다. 원래 X-Forwarded-For 헤더에 유효한 위치 정보가 포함되어 있더라도 Google은 부하 분산기에서 수신한 패킷에 포함된 소스 IP 주소 정보를 사용하여 클라이언트 위치를 추정합니다.

부하 분산기가 추가한 헤더는 이름이 동일한 기존 헤더를 덮어씁니다. 헤더 이름은 대소문자를 구분하지 않습니다. 헤더 이름이 HTTP/2 백엔드로 전달되면 HTTP/2 프로토콜은 헤더 이름을 소문자로 인코딩합니다.

헤더 값에서 선행 공백과 후행 공백은 유의하지 않으며 백엔드로 전달되지 않습니다. 부하 분산기는 헤더 값에 중괄호를 허용하기 위해 두 개의 여는 중괄호({{)를 하나의 여는 중괄호({)로 해석하고, 두 개의 닫는 중괄호(}})를 하나의 닫는 중괄호(})로 해석합니다.

상호 TLS 커스텀 헤더

부하 분산기의 TargetHttpsProxy에 상호 TLS(mTLS)가 구성된 경우 다음과 같은 추가적인 헤더 변수가 제공됩니다.

커스텀 요청 헤더 구성

gcloud compute backend-services create BACKEND_SERVICE_NAME \
    --global-health-checks \
    --global \
    --protocol HTTPS \
    --health-checks https-basic-check \
    --custom-request-header='HEADER_NAME:[HEADER_VALUE]'

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --global \
    --custom-request-header='HEADER_1_NAME:[HEADER_1_VALUE]' \
    --custom-request-header='HEADER_2_NAME:[HEADER_2_VALUE]'

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --global \
    --no-custom-request-headers

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME
"customRequestHeaders": [
   "client_city:Mountain View"
]

커스텀 응답 헤더 구성

gcloud compute backend-services (create | update) BACKEND_SERVICE_NAME
    --custom-response-header='HEADER_NAME:[HEADER_VALUE]'

gcloud compute backend-buckets (create | update) BACKEND_BUCKET_NAME
    --custom-response-header='HEADER_NAME:[HEADER_VALUE]'

gcloud compute backend-buckets update gaming-lab \
    --custom-response-header='X-Frame-Options: DENY'

gcloud compute backend-services update customer-bs-name \
    --global \
    --custom-response-header='Strict-Transport-Security: max-age=63072000'

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets

PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendBuckets/BACKEND_BUCKET_NAME

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices

PUT https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/BACKEND_SERVICE_NAME

"customResponseHeaders":HEADER_NAME:[HEADER_VALUE]

Cloud Storage의 응답 헤더 설정

Cloud Storage의 응답에 HTTP 헤더(예: 교차 출처 리소스 정책, X-Frame-Options 또는 X-XSS-Protection 헤더)를 설정해야 하는 경우 Google Cloud는 Cloud Storage를 통해 Cloud CDN용 커스텀 헤더를 사용할 수 있는 옵션을 제공합니다. 이 페이지에 설명된 대로 부하 분산기 백엔드 버킷 수준에서 커스텀 헤더를 구성하면 됩니다.

백엔드 버킷 수준에서 구성된 커스텀 응답 헤더는 클라이언트 요청이 부하 분산기 IP 주소로 전송되는 경우에만 응답에 추가됩니다. 클라이언트 요청이 Cloud Storage API로 직접 전송된 경우에는 커스텀 헤더가 응답에 추가되지 않습니다.

Google Cloud Armor에 커스텀 헤더 사용

Google Cloud Armor 보안 정책을 구성할 때 Google Cloud Armor에서 커스텀 헤더와 값을 삽입하도록 구성할 수 있습니다. Google Cloud Armor 보안 정책이 전역 외부 애플리케이션 부하 분산기 또는 기본 애플리케이션 부하 분산기의 커스텀 헤더와 동일한 커스텀 헤더 이름을 삽입하도록 구성된 경우 Google Cloud Armor 보안 정책에 지정된 헤더 값이 부하 분산기에서 채운 값을 덮어씁니다. Google Cloud Armor 정책을 덮어쓰지 않으려면 같은 이름을 사용하지 마세요.

제한사항

다음 제한사항은 전역 부하 분산기에 사용되는 커스텀 헤더에 적용됩니다.

• 각 백엔드 서비스에 대한 모든 커스텀 요청 헤더(변수 확장 전 이름 및 값 조합)의 총 크기는 8KB 또는 16개 요청 헤더를 초과하지 않아야 합니다.
• 각 백엔드 서비스에 대한 모든 커스텀 응답 헤더(변수 확장 전 이름 및 값 조합)의 총 크기는 8KB 또는 16개 응답 헤더를 초과하지 않아야 합니다.