Keycloak 및 인증 시스템에 대해서

시대생팀에서 쿠버네티스 클러스터를 옮기는 일을 하면서 새롭게 인프라를 세팅해야 하는 일이 있었다. Grafana나 Kiali 등을 온프레미즈에 다시 띄우면서 새롭게 세팅을 해야 했고, 우리의 인증을 담당하는 keycloak은 SOPF를 대비하기 위해서 온프레미즈에서 클라우드로 이전했기 때문에 세팅을 다시 진행해줘야 하는 상황이었다.

 

이 과정에서 여러 어려움을 겪었는데, Keycloak을 세팅하는 방법이 생각보다 복잡하기도 했고, 내가 기존에 알고 있던 인증 시스템 체계에 대한 지식이 생각보다 얕아서 좀 더 공부해야하기도 했다. 이번 포스팅에서는 인증 시스템의 키워드(oidc, SSO, OAuth etc)에 대해서 다루고, Keycloak이라는 솔루션에 대해서 소개하려고 한다.

 

 

로그인에 대하여

인증(Authentication)과 인가(Authorization)의 분리

로그인(login)이라는 단어가 인증과 인가를 한 덩어리로 느끼게 만들기 때문에, 조금 헷갈릴 수도 있다. 이 포스팅에서는 로그인이라는 표현 대신에 인증과 인가를 사용하도록 한다. 정리하자면 아래와 같다.

• 인증(Authentication) : "너 누구야?"를 확인하는 과정
• 인가(Authorization) : "너 뭐까지 할 수 있어?"를 결정하는 과정

대시보드를 예로 들면, Keycloak이라는 서비스를 통해서 로그인했다는 것은 "인증"에 해당하고, 특정 사용자는 Admin 폴더를 볼 수 있다 없다는 "인가(권한)"에 해당한다.

 

 

OAuth 2.0: 인가 표준

OAuth 2.0은 인증 표준이 아니라, 제3자 애플리케이션이 리소스에 제한된 접근 권한을 얻도록 하는 권한 위임(Authorization Delegation) 프레임워크이다. 그렇다면 '이론적'으로는 OAuth는 그냥 권한만 주는 것이다. 인증을 해주지는 않는다. 그렇다면 우리가 흔히 'Google OAuth를 구현한다'라면서 로그인을 구현하는데, 그건 어떻게 된 일인가? 인증은 누가 해줄까?

• [oauth.net] : https://oauth.net/2/

OAuth 2.0 — OAuth

 

해당 레퍼런스를 살펴보면, 상단에 다음과 같이 나와있는 것을 볼 수 있다.

OAuth 2.0 is the industry-standard protocol for authorization. OAuth 2.0 focuses on client developer simplicty while providing specific authorization flows for web applications - oauth.net/2/

 

즉, 인가(Authorization)에 대한 부분을 담당하는 것을 알 수 있다. OAuth가 주는 것은 "너 누구냐"가 아니라, "이 토큰을 가진 주체가 무엇을 할 수 있냐"에 초점이 있다. 그래서 업계에서 "OAuth 로그인"이라는 표현을 흔하게 사용하지만, 엄밀히 말하면 로그인(인증)을 표준화한 것은 OAuth가 아니다. 바로 OIDC이다.

 

 

OIDC(OpenID Connect) : 인증 레이어

OIDC는 한 문장으로 설명하면, OAuth 2.0 위에 인증(Identity) 개념을 표준화한 것이다. OIDC는 OAuth와 함께 붙어 다니는 것을 알아야 하는데, 이 내용은 위 레퍼런스에도 나와있는 내용이다.

oauth.net/2/

 

위 레퍼런스에서 스크롤을 내리다보면 Protocols Built on OAuth 2.0이라는 헤더에 OpenID Connect라는 레퍼런스가 있는 것을 볼 수 있다. 즉 OIDC는 OAuth 2.0 위에 올라가는 인증(Authencation) 레이어라는 것을 알 수 있다.

 

OIDC는 인가만 제공하는 OAuth와는 다르게 추가적으로 인증을 제공하며, 인증/인가에 대한 가장 일반적인 시나리오를 제공한다. 우리가 생각하는 일반적인 다른 플랫폼을 통한 로그인은 OIDC + OAuth 2.0이 섞여 있는 것이라고 볼 수 있다. 일반적으로 OIDC를 사용하는 프로세스는 아래와 같이 그려진다.

 

https://blog.logto.io/what-is-oidc

OAuth 2.0 위에서 사용자 인증을 가능하게 하고, 한계를 해결하기 위해서 OIDC는 세 가지 역할을 도입했는데, 위 사진을 바탕으로 소개하면 다음과 같다.

• End User : 최종 사용자로, OAuth 2.0의 리소스 소유자에 해당한다.
• Relying Party : OAuth 2.0의 클라이언트에 해당하는 종속 당사자
• OpenID Provider : Identity 인증 서비스 공급자로, Oauth 2.0 표준에서 나오는 Authorization/Resource Server에 해당한다.

여기에서, OpenID Provider는 핵심적인 역할을 하며, OAuth 2.0의 인가 기능을 제공하고 사용자 정보를 별도의 자원으로 취급한다. 이에 대한 상세한 레퍼런스는 아래의 사이트에서 확인할 수 있다.

• [logto] what is oidc : https://blog.logto.io/what-is-oidc

What is OIDC: From why we need it to how it works · Logto blog

 

다음으로는 기타 인증/인가 시스템에서 들어봤을 법한 용어의 정리이다.

 

 

기타 인증/인가 키워드

SSO(Single Sign-On) : 프로토콜이 아니라 구성

SSO라는 키워드를 사용하기도 하는데, 이는 OAuth/OIDC 같은 프로토콜이 아니라, 한 번 로그인으로 여러 서비스에 재로그인 없이 들어가는 사용자 경험/구성을 의미한다.

 

예를 들어서, 한국 개발자라면 다양한 SSO를 경험해 보았을 것이다. 카카오톡을 기반으로 다양한 카카오 서비스를 이용한다면, 카카오의 Identity를 통해서 다른 서비스도 바로 이용할 수 있고, 네이버 관련 서비스를 이용한다면 이미 로그인된 네이버 Identity를 통해서 간편하게 이용할 수 있는데, 이 부분이 SSO에 해당한다. 이러한 SSO는 사용자 경험에 해당한다.

 

 

SAML 2.0 : XML 기반의 SSO

SAML(Security Assersion Markup Language)는 외부 애플리케이션 및 서비스에 사용자가 자신이 누구인지 알려주는 표준화된 방법이다. 이것은 OAuth/OIDC와 함께 표준화된 방법이기 때문에 프로토콜이라고 불린다. SAML은 사용자를 한 번 인증한 다음 해당 인증을 여러 애플리케이션에 전달하는 방법을 제공하여 SSO를 가능하게 한다.

 

SAML의 인증 방식은 일반적으로 사용자와 IDP(Identity Provider) 그리고 서비스 공급자(Service Provider)로 이루어진다.

 

IDP(Identity Provider)는 일반적으로 로그인 프로세스를 통해 사용자 ID를 저장하고 확인하는 서비스이다. 기본적으로 IDP는 "나는 이 사람을 알고, 이 사람이 할 수 있는 일은 다음과 같다"와 같이 알려주는 일을 한다.

 

SP(Service Provider)는 사용자가 사용하고자 하는 클라우드 호스팅 애플리케이션이나 서비스를 의미한다. 일반적인 예로는 Gmail이나 Google 드라이브 그리고 AWS 등이 될 수 있다.

 

즉, 우리가 서비스에 접근하고자 하는데, 신원을 서비스 제공자에서 줄 수 있겠지만-이는 일반적으로 서비스에 내장되어 있는 로그인 시스템이다-그렇게 하지 않고, IDP를 통해서 접근을 하는 것이다. 대표적으로는 Google을 통해서 로그인을 하는 방법이 있다. 실제로 saml2aws라는 솔루션이 있다.

 

➜  ~ ✗ sudo saml2aws login
Password: # password 입력
Using IdP Account default to access GoogleApps https://accounts.google.com/o/saml2/initsso?idpid=88888888&spid=000000000&forceauthn=false
To use saved password just hit enter.
? Username marsboy@text.com
? Password

Authenticating as marsboy@text.com ...
Check your phone and tap 'Yes' on the prompt. Then press ENTER to continue.

 

다음과 같이 AWS에 접근하기 위해서 GoogleApps를 통해서 Assertion을 손쉽게 받을 수 있다. 이제 로컬에서는 세션이 유효한 기간 동안 AWS에 접근할 수 있게 된다. 저 명령어를 실행하고 나면 핸드폰으로 "본인이 맞습니까?" 라는 google gmail로 알림이 오는데, YES를 터치하면 정상적으로 신원이 연결된다.

 

이러한 대표적인 saml2aws라는 스크립트는 다음의 깃허브 페이지에서 볼 수 있다.

• [github] saml2aws : https://github.com/Versent/saml2aws

GitHub - Versent/saml2aws: CLI tool which enables you to login and retrieve AWS temporary credentials using a SAML IDP

 

지금까지 나왔던 인증/인가 관련 키워드를 표로 정리하면 아래와 같다고 볼 수 있다.

키워드	정체	주 목적	Output	한 줄
OAuth 2.0	인가 프레임워크	API가 접근 권한 위임	Access Token (주로 JWT)	내 대신 API 쓰게 해줘
OIDC	인증 표준	로그인 + 표준 사용자 정보	ID Token(JWT) + userinfo(Optional)	로그인 결과를 표준으로
SAML 2.0	인증/SSO 표준	엔터프라이즈 SSO	SAML Assertion(XML)	XML로 SSO
SSO	사용자 경험/구성	한 번 로그인으로 여러 서비스	(OIDC/SAML 등으로 구현되는 것)	한 번 로그인하면 끝

 

중간중간에 Keycloak이라는 솔루션 이름이 많이 나왔다. 이제는 본격적으로 Keycloak에 대해서 알아볼 차례이다.

 

---

 

Keycloak이란 무엇인가?

Keycloak은 "중앙 인증 허브"로 쓰기 좋은 오픈소스 IAM(Identity and Access Management) 솔루션이다. 공식 사이트에 따르면 Keycloak이 제공하는 핵심적인 기능은 다음과 같다.

 

• 애플리케이션/서비스를 중앙에서 관리
• 사용자/세션/권한 관리
• Identity Brokering(외부 IdP 연동) 및 User Federation(외부 사용자 저장소 연동)
• 세분화된 인가 정책 등

즉 Keycloak을 도입하면, 각 서비스(예를 들면, grafana, argocd, 사내 어드민 등)가 제각각 계정/비밀번호/정책을 들고 있지 않아도 되고, 인증/정책을 한 곳으로 모을 수 있다. 현업에서 어떠한 이유로 Keycloak을 사용하는지 좀 더 정리하면 아래와 같이 정리할 수 있다.

 

Keycloak이 특히 유용한 기능들

• OIDC Provider 역할 : OIDC 표준 엔드포인트 제공, 토큰 발급/검증 기간 로그인 구현
• SAML 연동 : SAML 기반 SSO가 필요한 시스템과도 붙일 수 있음
• Identity Brokering : Google/Github 같은 외부 IdP를 붙여 "Keycloak을 관문으로" 로그인 통합
• User Federation : LDAP/AD 같은 기존 사용자 디렉토리를 그대로 활용
• Role/Group 기반 권한 모델 : 토큰 Claim에 roles/groups를 실어 서비스 권한과 매핑
• MFA, 세션 관리, 패스워드 정책 같은 보안 기능 (운영이나 보안 난이도를 내릴 수 있다)

위와 같이 정리해볼 수 있다. 개인적으로는 Keycloak을 사용하는 큰 이유로써는 Role/Group 기반 권한 모델과 세션 관리등을 주된 요소로 보고 있다.

 

실제로 그라파나 대시보드를 구현하는 과정에서, 그라파나에서 쓰이는 대표적인 권한들(Admin, Editor, Viewer)이 있고, Keycloak에서 사용하는 권한들도 있다. 인프라 담당자는 sre, 개발자는 developer 그 외 무관부서는 manager라는 권한을 받는데, 이는 내부적으로 roles-mapping을 통해서 각각의 Keyclaok의 역할이 그라파나의 특정 역할에 매핑되도록 풀어나갈 수 있다.

 

또 다른 강점은, 만약에 Keycloak 같은 IdP를 사용하지 않는다면 퇴사자가 발생했을 때에 계정을 정리하는 부분이 쉽지 않고 놓칠 위험이 있지만, 간단하게 Keycloak의 계정을 뽑아버리는 것으로 다른 서비스 모두 사용하지 못하게 할 수 있다. 반대로 말하면 Keycloak을 쓰지 안/못하는 서비스들이 있는데, 대표적으로 n8n을 셀프 호스팅하고 있는 상황에서는 유료 버전을 사용하지 않으면 oidc를 제공해주지 않아서 그냥 개인 이메일로 로그인하도록 하고 있는데, 이렇게 되면 나중에 보안이나 감독이 어려워지는 문제가 발생한다.

 

그렇다면 이제 본격적으로 Keycloak을 연동하는 방법에 대해서 살펴보자.

 

 

Keycloak 기반으로 OIDC 구현하기

여기에서부터는 Keycloak을 통해서 grafana 대시보드에 oidc를 연결하고 roles를 전달하는 방법에 대해서 다룬다. Keycloak의 전반적인 세팅 과정을 생략한 이유는 Keycloak이라는 서비스의 사용 방법을 알리기보다는 어떤 식으로 Keycloak에서는 OIDC를 사용하고 있는지 정도만 소개하여, Keycloak의 스니펫을 보이기 위함이다.

 

참고로, OIDC를 적용할 매니지먼트 툴들은 gitOps 기반으로 helm chart를 벤더링해서 구현되어 있는 상황이며, 이번 포스팅에서는 해당 helm chart의 values 파일을 수정하는 방식으로 진행될 예정이다.

 

메인 페이지

 

다음과 같이 시대생팀의 Internal keycloak realm에서 grafana라는 client를 검색하면 나오는 것을 확인할 수 있다. 이런 식으로 Client를 등록하는 것을 OIDC 용어로는 RP/Relying Party라고 한다. 이와 같이 Client ID를 생성하고, Type을 OpenID Connect로 지정해준다. 

 

client 생성 페이지

 

클라이언트 생성 페이지에서 type과 ID를 제대로 정했다면 다음으로는 추가적인 설정을 진행할 수 있다.

두 번째 페이지

 

이렇게 Client Authentication 설정을 On으로 설정하고 나서, clinet를 생성하면 성공적으로 RP가 생성된다. 여기에서 끝나는 것이 아니라, 다음으로는 Grafana 대시보드를 띄우는 과정에서 해당 OIDC를 정상적으로 활용할 수 있도록 등록해줘야 한다.

 

Clients -> Credentials

 

새롭게 생성한 Clients의 Credentials 페이지에 진입하면 Client Secret을 확인할 수 있다. 해당 Secret을 통해서 grafana에 OIDC를 설정할 수 있다. 추가적으로 앞서 말했듯이, grafana에서 쓰는 roles 체제와 keycloak에서 조직 내 정의한 roles 체제가 다르기 때문에 이에 맞게 설정을 진행해줘야 한다. 

 

grafana에서 사용하는 roles

 

grafana에서 roles를 정의하기 위해서 client -> roles 탭으로 향한다. create role를 통해서 admin과 editor를 생성했다. 원한다면 그냥 viewer를 생성해도 좋다.

Associated Roles

 

다음으로, roles를 눌러 keycloak 내에 있는 어떤 역할을 grafana의 어떤 역할에 매치시킬 건지에 대해서 설정할 수 있다. 여기까지 설정이 완료되었다면, 다음으로는 그라파나의 헬름 차트를 세팅할 차례이다.

 

 

Grafana Helm 세팅

Keycloak 쪽에서 Grafana에 대한 클라이언트를 활성화해 두었다면, 다음으로는 그라파나를 설정하는 데 있어서 해당 key를 세팅해야 한다. helm chart 기반으로 설정할 수 있다. values.yaml 파일에 다음과 같이 등록한다.

 

grafana:
  grafana.ini:
    auth.generic_oauth:
      enabled: true
      name: Keycloak
      allow_sign_up: true
      client_id: grafana
      client_secret: $__file{/etc/secrets/grafana_oidc_client_secret}
      scopes: "openid profile email"
      auth_url: "https://<KEYCLOAK>/realms/<REALM>/protocol/openid-connect/auth"
      token_url: "https://<KEYCLOAK>/realms/<REALM>/protocol/openid-connect/token"
      api_url: "https://<KEYCLOAK>/realms/<REALM>/protocol/openid-connect/userinfo"

 

위와 같이 등록하고 설정을 적용하면 성공적으로 grafana 대시보드에 OIDC 로그인 컴포넌트가 생기게 된다. 

Sign in with UOSLIFE가 생겼다

 

helm chart를 사용하는 grafana를 기준으로는 위와 같이 설정할 수 있으며, 그 외에 설정의 경우에도 그라파나의 공식 문서를 참고하면 다양한 것들을 살펴볼 수 있다. 

 

• [grafana] Configure Grafana : https://grafana.com/docs/grafana/latest/setup-grafana/configure-grafana/

Configure Grafana | Grafana documentation

 

직접 벤더링해서 사용했던 grafana의 helm chart의 values.yaml 파일은 다음의 레퍼런스에서 살펴볼 수 있다.

• [github] grafana chart : https://github.com/grafana/helm-charts/blob/main/charts/grafana/values.yaml

helm-charts/charts/grafana/values.yaml at main · grafana/helm-charts

 

위 깃허브 레포지토리를 살펴보면 약 880번 라인부터 해당 내용을 찾아볼 수 있다.

grafana helm chart values.yaml

 

위와 같은 설정을 통해서 management 툴에 keycloak을 통한 oidc 세팅을 진행할 수 있으며, 다른 oidc를 지원하는 매니지먼트 툴 또한 비슷한 방법으로 진행하고, roles를 부여할 수 있다.

 

 

마치며

인증/인가 관련된 영어 문서를 번역하면서 봤는데, Authencation과 Authorization을 똑같이 '인증'으로 번역하는 곳이 많아서, 영어 문서로 전부 읽다 보니까 자료 조사하는데 시간이 꽤 걸렸네요. 다들 조심하시길 바랍니다.