블로그 | NGINX

Okta 및 NGINX Ingress Controller를 사용하여 Kubernetes에 대한 OpenID Connect 인증 구현

NGINX-F5-수평-검정-유형-RGB의 일부
아미르 라우드닷 썸네일
아미르 라우드다트
2021년 9월 22일 게시

오늘날 랜섬웨어와 봇 기반 공격이 만연한 환경에서 앱과 API를 보호하는 것이 얼마나 중요한지에 대해서는 이미 여러 번 말씀드렸습니다. 웹 애플리케이션 방화벽 (WAF)과 같은 메커니즘과 함께 사용자 신원 인증 및 권한 부여 제어 시행은 비즈니스 애플리케이션을 보호하는 중요한 방법입니다.

인증 및 권한 부여를 구현하는 가장 직접적인 방법은 애플리케이션 자체에 있습니다. 이 방법은 사용자 기반이 작고 앱에 자주 업데이트가 필요하지 않은 경우 효과적일 수 있지만, 규모가 커지면 빠르게 실행 불가능해집니다. 우선, 사용자가 여러 앱 각각에 대해 다른 계정 이름과 비밀번호를 기억해야 하는 경우 로그인을 시도할 때 종종 "잘못된 사용자 이름 또는 비밀번호"라는 짜증나는 메시지가 표시되어 쉽게 추측할 수 있는 "abc123" 비밀번호와 같은 안전하지 않은 솔루션을 사용하게 됩니다. 그리고 우리는 모두 비밀번호 알림을 담은 Post‑it® 노트로 장식된 모니터를 본 적이 있을 것입니다!

단일 로그인(SSO) 기술은 모든 개별 사용자 이름과 비밀번호를 제거하고 하나의 자격 증명 세트로 통합함으로써 이러한 문제를 부분적으로 해결할 수 있습니다. 사용자는 IdP(ID 공급자)를 통해 한 번만 로그인하여 여러 앱에 액세스할 수 있습니다. 하지만 개발자는 여전히 SSO 시스템과 상호 작용하기 위해 앱에 코드를 포함해야 하는데, 이는 특히 애플리케이션이 복잡해질수록 매우 어려울 수 있습니다.

조직이 확장되고 급증하는 사용자 기반의 요구 사항을 충족해야 함에 따라 인증 및 권한 부여와 같이 앱의 기능에 국한되지 않은 요구 사항을 애플리케이션 계층에서 오프로드하는 것이 중요해집니다. Kubernetes 에서 중앙화된 인증 및 권한 부여를 위한 이상적인 위치는 Ingress 컨트롤러 입니다. 이 컨트롤러는 클러스터에 들어오는 모든 트래픽을 면밀히 조사하고 적절한 서비스로 라우팅할 수 있습니다. 이를 통해 개발자는 인증 로직을 구축, 유지 관리, 복제하는 부담으로부터 해방되고 기본 Kubernetes API를 사용하여 수신 계층에서 SSO 기술을 쉽게 활용할 수 있습니다.

이 블로그에서는 NGINX Plus 기반 NGINX Ingress Controller를 릴레이 당사자로 작동시키고, Okta를 사전 구성된 ID 공급자(IdP)로 사용하여 OIDC 인증 코드 흐름을 지원하는 본격적인 SSO 솔루션을 구현하는 방법을 보여줍니다.

메모: 이 기능은 NGINX 오픈 소스 기반 NGINX Ingress Controller에서 사용할 수 없습니다.

필수 조건

이 블로그에서는 독자가 Kubernetes 환경에서 운영 경험이 있다고 가정합니다. 추가로 다음 사항이 필요합니다.

  • Kubernetes 환경 – NGINX Ingress Controller는 vanilla Kubernetes뿐만 아니라 Amazon Elastic Kubernetes(EKS), bare metal, Google Kubernetes Engine(GKE), Microsoft Azure Kubernetes Service(AKS), Rancher Kubernetes Engine, Red Hat OpenShift를 포함한 수많은 Kubernetes 플랫폼에서도 지원됩니다.
  • NGINX Plus 기반 NGINX Ingress Controller – NGINX Plus 기반 버전의 NGINX Ingress Controller에 대한 유효한 라이선스가 있어야 합니다. 오늘 무료 30일 체험판을 요청하여 라이선스를 받아보세요. 자세한 내용은 설명서를 참조하세요.
  • Okta 개발자 계정 – Okta를 IdP로 구성하려면 먼저 개발자 계정에 가입하세요. 또는 Okta 명령줄 인터페이스 (CLI)를 다운로드하고 okta register 명령을 실행하여 새 계정에 가입하세요. 이 글을 쓰는 시점에서 Okta CLI는 베타 상태이며 실제 운영에는 권장되지 않습니다.

IdP 사전 구성

클라우드 서비스는 사용자 신원을 검색하고 검증할 위치를 알아야 하며, 이때 IdP가 필요합니다. IdP는 디지털 신원을 안전하게 관리하고 저장하며 공격자가 사용자를 사칭하기 위해 신원을 도용하지 못하도록 보장합니다.

이 섹션에서는 Okta CLI를 사용하여 Okta를 IdP로 미리 구성하여 Okta가 앱 통합 이라고 부르는 것을 만듭니다.

  1. Okta 개발자 계정으로 Okta CLI를 인증하려면 okta login 명령을 실행하세요. 프롬프트에 Okta 도메인과 API 토큰을 입력하세요.

    $ okta 로그인 Okta Org URL: https:// your-okta-domain Okta API 토큰: your-api-token

  2. 앱 통합을 만듭니다.

    $ okta 앱 생성 --앱 이름=mywebapp --리디렉션 URI=http[s]:// ingress 컨트롤러 호스트 이름 /_codexch

    어디

    • --app-name은 애플리케이션 이름을 정의합니다(여기서는 mywebapp ).
    • --redirect-uri는 로그인이 리디렉션되는 URI를 정의합니다(여기서는 ingress-controller-hostname /_codexch )

  3. 프롬프트에 응답하여 먼저 애플리케이션 유형을 지정하십시오.1 (웹 애플리케이션을 나타냄) 그리고5 (나열된 것 외의 프레임워크를 나타냄).

    애플리케이션 유형
(Okta CLI는 애플리케이션 유형 및 속성의 하위 집합만 지원합니다):
> 1: 웹
> 2: 단일 페이지 앱
> 3: 네이티브 앱(모바일)
> 4: 서비스(Machine-to-Machine)
선택 사항을 입력하세요 [웹]: 1
응용 프로그램 유형
> 1: Okta Spring Boot Starter
> 2: 스프링 부트
> 3: J힙스터
> 4: 쿼커스
> 5: 기타
선택 사항을 입력하세요 [기타]: 5
새로운 OIDC 애플리케이션 구성, 거의 완료:
OIDC 애플리케이션 생성, 클라이언트 ID: 0oa1mi...OrfQAg5d7

NGINX Ingress 컨트롤러 구성

NGINX Ingress Controller의 NGINX Plus 기반 버전을 사용자를 인증하는 릴레이 당사자로 구성합니다.

클라이언트 자격 증명 비밀 정의

보안상의 이유로 OIDC 정책 개체에 클라이언트 비밀번호를 하드코딩하는 것은 지원되지 않습니다. 대신 클라이언트 비밀의 base64로 인코딩된 값을 포함하는 데이터로 Kubernetes 비밀을 생성합니다.

apiVersion: v1 종류: 비밀 메타데이터: 이름: oidc-secret 유형: nginx.org/oidc 데이터: 클라이언트-비밀: base64-encoded-value-of-client-secret

그런 다음 비밀을 포함하는 YAML 파일을 적용합니다(여기서는 client-secret.yaml ).

$ kubectl 적용 –f 클라이언트-비밀.yaml

인증 엔드포인트 가져오기

OAuth 2.0 및 OpenID Connect API를 사용하여 Okta가 인증 서버에 노출하는 엔드포인트에 대한 정보를 가져옵니다.

Okta 엔드포인트에 대한 정보를 출력하려면 로컬 머신에서 다음 명령을 실행하세요. 샘플 출력에 표시된 authorization_endpoint , token_endpoint 및 jwks_uri 의 값을 기록해 보세요. 다음 섹션 에서 이를 사용합니다.

$ curl -i https:// 귀하의 Okta 도메인 /.well-known/openid-configuration { "권한 부여_엔드포인트": "https:// 귀하의 Okta 도메인 /oauth2/v1/authorize", ... "jwks_uri": "https:// 귀하의 Okta 도메인 /oauth2/v1/keys", ... "토큰_엔드포인트": "https:// 귀하의 Okta 도메인 /oauth2/v1/토큰", ... }

NGINX Ingress OIDC 정책 정의

NGINX Ingress Controller 1.10.0에서 OIDC 기반 인증 지원이 추가되었습니다. 자세한 내용은 블로그에서 OpenID Connect와 NGINX Ingress Controller를 사용한 간편하고 강력한 Single Sign‑On을 읽어보세요.

NGINX Ingress Controller의 OIDC 인증 구현은 Policy 객체를 사용합니다. Policy 객체는 NGINX Ingress Controller에서 OIDC 정책을 정의하는 Kubernetes 사용자 정의 리소스입니다 .

  1. 이전 섹션에서 얻은 정보를 Policy 객체의 authEndpoint , tokenEndpoint , jwksURI 필드에 삽입합니다.

    api버전: k8s.nginx.org/v1 종류: 정책 메타데이터: 이름: oidc-policy 사양: oidc: clientID: 클라이언트 ID clientSecret: oidc-secret authEndpoint: https:// your-okta-domain /oauth2/v1/authorize tokenEndpoint: https:// your-okta-domain /oauth2/v1/token jwksURI: https:// your-okta-domain /oauth2/v1/keys

  2. 정책을 적용합니다(여기서는 oidc.yaml 에 정의되어 있음):

    $ kubectl 적용 -f oidc.yaml

  3. (선택 사항) 정책의 유효성을 확인하세요.

    $ kubectl get policy NAME STATE AGE oidc-policy 유효 기간 2m

VirtualServer 객체 정의

VirtualServer와 VirtualServerRoute는 Kubernetes 클러스터의 백엔드 애플리케이션으로 들어오는 트래픽을 라우팅하기 위한 규칙을 프로비저닝하는 NGINX Ingress 리소스 입니다. OIDC 정책을 적용하려면 VirtualServer 또는 VirtualServerRoute 리소스에서 참조되어야 합니다.

  1. / 경로 접두사 아래에 OIDC 정책을 참조하면 접두사와 일치하는 경로를 요청하는 사용자가 요청이 app-server-payload 서비스로 프록시되기 전에 인증됩니다.

    api버전: k8s.nginx.org/v1
종류: VirtualServer
메타데이터:
이름: app-ingress
스펙:
호스트: unit-demo.linkpc.net
업스트림:
- 이름: app-server-payload
서비스: app-server-svc
포트: 80
경로:
- 경로: /
정책:
- 이름: oidc-policy
작업:
프록시: 
업스트림: app-server-payload

  2. VirtualServer 리소스를 적용합니다(여기서는 app-virtual-server.yaml 에 정의됨):

    $ kubectl 적용 -f 앱 가상 서버.yaml

  3. (선택 사항) 리소스의 유효성을 확인하세요:

    $ kubectl get vs NAME STATE HOST IP PORTS AGE app-ingress Valid unit-demo.linkpc.net 2m

환경 테스트

OIDC Okta 통합이 제대로 작동하는지 테스트하려면 브라우저의 주소창에 NGINX Ingress Controller의 호스트 이름을 입력하세요. Okta 로그인 포털로 리디렉션됩니다. 여기서 Okta 개발자 계정의 자격 증명을 입력하면 백엔드 애플리케이션에 액세스할 수 있습니다.

성공적으로 인증되면 앱-서버-페이로드 업스트림 서비스에 액세스할 수 있습니다.

애플리케이션에 사용자 추가

대부분의 경우 조직 내의 여러 사용자가 앱에 액세스해야 합니다. Okta 관리 콘솔의 디렉토리 카테고리에 있는 사람 페이지에서 각 사용자를 추가합니다.

여러 앱에 대한 SSO 통합 생성

Okta를 IdP로, NGINX Ingress Controller를 릴레이 당사자로 하여 SSO를 구성함으로써 하나의 애플리케이션에서 인증 프로세스의 부담을 덜었습니다. 실제로는 사용자가 단일 자격 증명을 사용하여 여러 애플리케이션에 액세스할 수 있도록 하는 것이 좋습니다. 또한 사용자가 액세스할 수 있는 애플리케이션에 대한 유연성이 필요할 수도 있습니다. 위 섹션의 지침을 반복하면 이 작업을 수행할 수 있습니다.

다음 다이어그램에 나타난 예에서는 두 개의 하위 도메인인 unit-demo.marketing.net 과 unit-demo.engineering.net 이 있으며, 이는 NGINX Ingress Controller의 외부 IP 주소로 확인됩니다. NGINX Ingress Controller는 하위 도메인을 기반으로 마케팅 앱이나 엔지니어링 앱으로 요청을 라우팅합니다. 사용자에게 액세스 권한을 부여하려면 Okta GUI의 '할당' 탭에서 사용자를 각각의 적절한 애플리케이션에 연결합니다. 그러면 Okta는 인증된 사용자에게 해당 애플리케이션에 액세스할 수 있는 단기 세션 쿠키를 부여합니다.

NGINX Ingress Controller와 IdP인 Okta를 사용하여 단일 로그인을 위한 여러 앱 통합의 토폴로지 다이어그램

결론

NGINX Ingress Controller를 릴레이 당사자로, Okta를 IdP로 사용하여 Kubernetes에서 OIDC 기반 SSO를 구현하면 개발자의 인증 및 권한 부여에 대한 부담이 줄어들어 개발자는 앱에서 비즈니스 로직을 최적화하는 데 집중할 수 있습니다. NGINX Plus 기반 NGINX Ingress Controller를 시작하려면 오늘 무료 30일 평가판을 요청하거나 당사에 문의하여 사용 사례에 대해 논의해 보세요 .

F5 NGINX에 대한 더 많은 블로그 게시물 읽기 ›

"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."