인증된 액세스 (Authenticated Access)

Zuul의 REST API와 웹 인터페이스에 대한 접근은 선택적으로 제한할 수 있습니다. 기본적으로, 모든 테넌트(tenant)에 대한 익명 읽기 액세스가 허용됩니다. 선택적으로, 일부 관리 작업을 활성화하여 승인된 사용자로 제한할 수도 있습니다. 또한, 개별 테넌트나 전체 시스템에 대해 읽기 수준(read-level) 액세스를 승인된 사용자로 제한할 수도 있습니다.

지원되는 관리 작업은 autohold, enqueue/enqueue-ref, dequeue/dequeue-ref, 그리고 promote입니다. 이들은 Zuul CLI를 통해 사용할 수 있는 것들과 유사합니다.

보호된 엔드포인트는 베어러 토큰(bearer token)을 요구하며, 이는 요청의 Authorization 헤더로 Zuul 웹 서버에 전달됩니다. 토큰과 이 워크플로는 RFC 에 확립된 JWT 표준을 따릅니다.

중요 보안 고려 사항 (Important Security Considerations)

유효한 관리자 토큰을 가진 사람은 누구든 REST API를 통해 노출된 특권 작업(privileged actions)을 수행할 수 있습니다. 게다가 토큰을 취소(revoking)하는 것은, 특히 수동으로 발급된 경우 간단하지 않습니다.

이를 완화하기 위해, 토큰은 10분 이하와 같이 짧은 수명(time to live)을 가지도록 생성해야 합니다. 만약 토큰이 인가 정보(아래 zuul.admin 클레임 참조)를 포함하고 있다면, 토큰이 탈취되었을 경우의 공격 표면을 줄이기 위해 가능한 한 최소한의 범위(예: 단일 테넌트)로 생성해야 합니다.

관리 작업을 노출하면 빌드 결과(빌드셋 dequeue)에 영향을 줄 수 있으며, autohold 기능이 남용될 경우 상당수의 노드가 장기간 “hold” 상태로 남아 잠재적인 리소스 문제를 일으킬 수 있습니다. 언제나 그렇듯, “큰 힘에는 큰 책임이 따르며(with great power comes great responsibility)”, 토큰은 신중하게 전달되어야 합니다.

구성 (Configuration)

중요

Zuul 명령줄 인터페이스(CLI)에서 제한된 명령을 사용하려면, 적어도 하나의 HS256 인증자(authenticator)가 구성되어 있어야 합니다.

특권 작업에 대한 테넌트 범위(tenant-scoped) 액세스를 활성화하거나 읽기 수준 액세스를 제한하려면, Zuul 웹 서버 컴포넌트 섹션을 참조하세요.

테넌트에 대한 액세스 규칙을 설정하려면, 테넌트 정의에 관한 문서 를 참조하세요.

대부분의 경우, Zuul 구성에는 하나의 인증자만 필요합니다. 즉, dex, auth0, keycloak 등과 같은 타사 ID 제공자 서비스와 일치하는 구성입니다. 하지만 이와 유사한 다른 인증자를 추가하는 것이 유용할 때가 있습니다.

[auth zuul_operator]
driver=HS256
allow_authz_override=true
realm=zuul.example.com
client_id=zuul.example.com
issuer_id=zuul_operator
secret=exampleSecret

이러한 인증자가 있으면, Zuul 운영자는 필요할 경우 Zuul CLI를 사용하여 테넌트의 액세스 규칙을 재정의(override)하는 토큰을 발급할 수 있습니다. 그러면 사용자는 테넌트의 액세스 규칙을 수정할 필요 없이, 이 토큰을 Zuul CLI와 함께 사용하여 해당 테넌트에서 일시적으로 보호된 작업을 수행할 수 있습니다.

JWT 형식 (JWT Format)

Zuul은 다음과 같은 최소한의 클레임(claims) 집합을 가진 JWT를 사용할 수 있습니다.

{
 'iss': 'jwt_provider',
 'aud': 'my_zuul_deployment',
 'exp': 1234567890,
 'iat': 1234556780,
 'sub': 'alice'
}

iss: 토큰 발급자(issuer)입니다. ID 제공자를 필터링하는 데 사용할 수 있습니다.
aud: 의도된 수신자(audience)로, 보통 ID 제공자에 등록된 클라이언트 ID입니다.
exp: 토큰 만료 타임스탬프입니다.
iat: 토큰 발급 날짜 타임스탬프입니다.
sub: 사용자의 기본 고유 식별자(identifier)입니다.

JWT는 다른 클레임으로 임의 확장될 수 있습니다. 하지만 인증자 구성에서 allow_authz_override 옵션이 True로 설정된 경우, Zuul은 특정 zuul 클레임을 찾을 수 있습니다. 이 클레임은 다음과 같은 형식을 가집니다.

{
 'zuul': {
    'admin': ['tenant-one', 'tenant-two']
  }
}

admin 필드는 토큰 소유자가 특권 작업을 수행할 권한을 부여받은 테넌트들의 목록입니다.

JWT 수동 생성 (Manually Generating a JWT)

운영자는 zuul.conf에 구성된 인증자의 설정을 사용하여 JWT를 생성할 수 있습니다.

예를 들어, Python에서 HS256 알고리즘을 사용하는 인증자의 경우 다음과 같습니다.

>>> import jwt
>>> import time
>>> jwt.encode({'sub': 'user1',
                'iss': <issuer_id>,
                'aud': <client_id>,
                'iat': int(time.time()),
                'exp': int(time.time()) + 300,
                'zuul': {
                         'admin': ['tenant-one']
                        }
               }, <secret>, algorithm='HS256')
'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ6dXVsIjp7ImFkbWluIjpbInRlbmFudC1vbmUiXX0sInN1YiI6InZlbmttYW4iLCJpc3MiOiJtYW51YWwiLCJleHAiOjE1NjAzNTQxOTcuMTg5NzIyLCJpYXQiOjE1NjAzNTM4OTcuMTg5NzIxLCJhdWQiOiJ6dXVsIn0.Qqb-ANmYv8slNUVSqjCJDL8HlH9L7nnLtLU2HBGzQJk'

https://jwt.io 와 같은 온라인 리소스를 통해서도 JWT를 생성, 디코딩 및 디버깅할 수 있습니다.

디버깅 (Debugging)

문제가 발생할 경우:

구성이 올바른지, 특히 콜백(callback) URI를 확인하세요.
더 많은 정보는 Zuul 웹 서비스 로그에서 찾을 수 있습니다.
사용자 측면에서는, 브라우저의 웹 콘솔을 활성화하는 것이 API 호출을 디버깅하는 데 도움이 될 수 있습니다.

다른 시스템과의 연동 (Interfacing with Other Systems)

다음은 관리자가 Zuul 및 Zuul 웹 UI에서 OpenID Connect 인증을 활성화하는 데 도움이 되는 몇 가지 방법(how-tos)입니다.