새로운 티타늄 클라우드 서비스는 귀하를 위해 740개의 기술 건조 제품을 공유했습니다.
Kubernetes는 오늘날 가장 널리 사용되는 오픈 소스 컨테이너 오케스트레이션 플랫폼이지만 적어도 기본적으로는 사용자를 생성하고 관리할 수단이 없습니다. 그러나 이는 여러 인증 서비스와 인터페이스할 수 있으므로 단점이 아닙니다. 이로 인해 Dex는 Kubernetes에서 사용할 수 있는 최고의 인증 솔루션 중 하나가 되었습니다.
이 문서에서는 Kubernetes용 Dex에 대해 자세히 알아봅니다. Dex 가 해결할 수 있는 몇 가지 문제를 살펴보고 , 타사 ID 공급자와 함께 설정하는 방법에 대한 높은 수준의 개요를 살펴보고, Dex가 다루지 않지만 여전히 해결해야 할 몇 가지 문제를 고려할 것입니다 .
덱스가 무엇인가요?
Dex 는 OpenID Connect(OIDC)를 사용하여 수많은 ID 공급자와 Kubernetes 및 기타 OIDC 호환 서비스를 연결하는 CoreOS, Inc.에서 출시한 오픈 소스 CNCF 샌드박스 프로젝트 및 인증 서비스입니다. 즉, Dex를 kubectl Okta, GitHub, Google, Microsoft 및 Linkedin과 같이 널리 사용되는 ID 공급자 간의 중개자로 생각할 수 있습니다.
쿠버네티스와 다른 ID 제공자 간의 다리 역할을 하는 Dex 의 기능을 통해 관리자는 여러 팀이 있는 조직에 필수적인 중앙 집중식 사용자 및 그룹 관리를 구현할 수 있습니다.
또한 다음 섹션에서 배우게 될 것처럼 Dex는 보안을 강화하고 Kubernetes에 현대적이고 편리한 로그인 환경을 제공합니다 .
Kubernetes용 Dex는 어떻게 작동합니까?
Dex의 작동 방식을 살펴보기 전에 Kubernetes 인증 프로세스의 작동 방식을 이해하는 것이 중요합니다.
Kubernetes 클러스터와 통신할 때 kubectl실제로 API 서버와 상호 작용합니다. API 서버에 대한 모든 HTTP 요청에 대해 인증 플러그인은 사용자 이름, UID 및 그룹을 조회합니다. 이러한 속성은 클라이언트 인증서, 인증 프록시 또는 전달자 토큰에서 제공할 수 있습니다. 여기에서 Dex가 신원 공급자와 kubectl클라이언트 사이의 다리 역할을 합니다.
Dex는 OIDC를 사용하므로 소위 "커넥터"를 사용하여 타사 ID 공급자에 저장된 사용자 정보에 액세스할 수 있습니다. 이를 통해 Dex는 사용자 정보를 베어러 토큰 형태로 Kubernetes에 전달하여 인증 프로세스를 완료할 수 있습니다. 이 모든 것은 SSO(Single Sign-On) 프로세스를 통해 수행되므로 사용자에게 투명합니다 .
또한 다음 섹션에서 설명하겠지만 Dex가 보낸 ID 토큰에는 사용자 인증에 사용할 수 있는 정보가 포함되어 있습니다.
위의 프로세스는 Kubernetes에서 인증이 작동하는 방식을 단순화한 것입니다. 인증 프로세스에 대한 자세한 내용은 공식 Kubernetes 문서를 확인하세요.
(https://kubernetes.io/docs/reference/access-authn-authz/authentication/)
Dex는 어떤 문제를 해결합니까?
관리자가 조직의 ID 서비스 공급자를 사용하여 사용자 및 그룹을 관리할 수 있도록 Dex가 Kubernetes의 기능을 확장한다고 이미 언급했습니다.
그러나 Dex가 해결하는 유일한 문제는 아닙니다. 그것이 제공하는 다른 이점 중 일부를 살펴 보겠습니다 .
0 1
보안 향상
Dex는 여러 가지 방법으로 Kubernetes 클러스터의 보안을 개선합니다.
ID 공급자를 통해 사용자를 클러스터에 안전하게 로그인할 수 있는 방법을 제공합니다.
여러 사용자가 동일한 kubeconfig 파일을 사용하는 것과 관련된 보안 위험을 제거합니다.
감사 로그를 통해 각 사용자가 수행한 작업을 효과적으로 탐지할 수 있습니다.
시간 제한 없이 무기명 토큰을 생성하는 관행을 제거합니다.
RBAC 규칙(Zero Trust RBAC 액세스)을 사용하여 효율적인 사용자 및 그룹 관리로 인해 인증 및 권한 부여 정책을 시행하는 데 도움이 됩니다.
0 2
유연성
모든 조직에는 고유한 요구 사항이 있으며 Dex는 거의 모든 ID 공급자를 사용할 수 있을 만큼 유연합니다. Okta, GitHub, GitLab, Microsoft, Linkedin 및 OpenID Connect, OAuth 2.0, LDAP 및 SAML 2.0 프로토콜을 사용하는 서비스에 사용 가능한 커넥터. Dex에 대한 자세한 내용은 깃허브 주소를 운영해주세요. (https://github.com/dexidp/dex)
0 3
중앙 집중식 인증 시스템 제공
Dex를 구현하는 것은 소규모 팀에게는 최상의 솔루션이 아닐 수 있습니다. 그러나 여러 팀에 수십 명의 사용자가 있는 조직의 경우 Dex는 매우 강력한 도구입니다. kubeconfig 파일을 수동으로 생성, 관리 및 배포할 필요가 없다는 것은 시간 절약 및 보안 측면에서 큰 이점입니다.
또한 Dex는 보다 세분화된 액세스 제어를 지원하여 Kubernetes를 보완합니다. 다음 섹션에서 볼 수 있듯이 Dex는 ID 토큰의 발급을 제어하여 임시 사용자 액세스와 관련된 상황에 편리한 기간을 지정할 수 있습니다.
또한 필요한 경우 모든 ID 토큰을 취소할 수 있습니다. 특정 사용자 또는 그룹에 대한 액세스 권한을 취소할 수도 있습니다.
대체로 Dex를 사용하면 효율적이고 사용하기 쉬운 중앙 집중식 인증 시스템을 Kubernetes에 추가할 수 있습니다.
Kubernetes에서 Dex 사용
인증 설정
이미 설정한 것처럼 Dex는 커넥터를 사용하여 Kubernetes를 여러 ID 공급자와 연결하는 포털 역할을 합니다.
다음 다이어그램은 Single Sign-On 프로세스에 대한 높은 수준의 개요를 제공합니다.
인증 프로세스 중에 다음 단계가 수행됩니다.
최종 사용자가 Dex에 로그인 요청을 시작합니다. 이것은 일반적으로 싱글 사인온 웹 애플리케이션 또는 포털을 실행하는 사용자가 수행합니다.
Dex는 이 요청을 타사 ID 공급자(예: Active Directory, Google, GitHub 또는 Okta)로 전달합니다. 이를 위해 Dex는 다른 사용자 관리 시스템을 쿼리하기 위한 프로토콜 세트가 있는 "커넥터"를 사용합니다.
이러한 "커넥터" 덕분에 Dex는 ID 공급자로부터 이름, 이메일, 고유 식별자, 그룹, 액세스 토큰 등과 같은 관련 사용자 정보에 액세스할 수 있습니다. Okta의 경우 이 데이터는 ID 토큰의 형태로 제공됩니다. Dex 설명서에 따르면 "ID 토큰은 JWT(JSON Web Tokens)입니다. 최종 사용자의 신원을 증명하는 OAuth2 응답의 일부로 반환됩니다."
Dex가 제3자 업스트림 자격 증명 공급자로부터 사용자 정보를 얻으면 자격 증명 공급자 역할을 맡고 서명된 ID 토큰을 클라이언트에 발급하여
kubectlJWT를 API 서버로 전달합니다.API 서버는 Kubernetes OpenID Connect 토큰 인증자 플러그인을 사용하여 ID 토큰을 사용합니다. 이 시점의 결과는 사용자를 인증하거나 거부할 수 있습니다. 사용자가 성공적으로 인증되면 API 서버는 ID 토큰 정보를 사용하여 RBAC 규칙을 적용합니다.
API 서버의 응답은
kubectl클라이언트로 다시 전송됩니다.클라이언트는
kubectl최종 사용자에게 결과를 표시합니다.
LDAP를 통한 인증에 대한 정보는 여기(https://dexidp.io/docs/connectors/ldap/)에서 설명서를 참조하십시오. Okta와 같은 OpenID Connect 공급자로 인증하는 방법에 대한 추가 정보는 여기(https://dexidp.io/docs/connectors/oidc/)에서 설명서를 참조하십시오.
Dex가 해결하지 못하는 문제는 무엇입니까?
Dex는 Kubernetes 싱글 사인온 경험을 찾는 조직에 탁월한 솔루션을 제공하지만 특정 ID 공급자와 관련된 제한 사항에서 면제되지 않습니다.
Dex 설명서(https://github.com/dexidp/dex)에서 알 수 있듯이 모든 자격 증명 공급자가 새로 고침 토큰 요청을 지원하는 것은 아닙니다. 즉, ID 공급자에 따라 사용자는 때때로 이전 섹션에서 설명한 인증 프로세스를 반복해야 합니다.
또한 모든 Dex 커넥터가 안정적인 것은 아닙니다. Google, Bitbucket Cloud 및 OAuth 2.0용 커넥터는 아직 알파 상태입니다.
명심해야 할 또 다른 점은 Dex가 인증 솔루션으로만 사용된다는 것입니다. 환경 변수, kube 컨텍스트 및 비용 관리는 수동으로 또는 다른 도구를 사용하여 수행해야 합니다.
결론적으로
이 기사에서는 Dex가 Kubernetes를 사용한 더 나은 로그인 경험을 위한 실행 가능한 솔루션임을 배웠습니다.
OIDC 공급자인 Dex를 사용하면 조직에서 사용 중인 ID 공급자를 사용하여 Kubernetes에 연결할 수 있습니다.
추가 인프라를 추가하지 않고도 조직에서 Kubernetes에 대한 중앙 집중식 ID 관리를 구현하여 시간을 절약하고 보안 정책을 개선할 수 있기 때문에 이는 큰 이점입니다.
원본: https://loft.sh/blog/dex-for-kubernetes-how-does-it-work/
권장 독서
추천 동영상