dex app
v1.42.13
Dex는 OpenID Connect를 사용하여 Kubernetes에 대한 인증을 처리하는 ID 서비스입니다. Active Directory, LDAP, GitHub와 같은 타사 ID 공급자에 연결됩니다. Kubernetes API 서버는 단일 ID 공급자와 OIDC 토큰 발급자만 지원하지만 Dex를 사용하면 Kubernetes를 인증할 때 다양한 공급자의 ID를 사용할 수 있습니다.
이 앱은 기본적으로 Giant Swarm 관리 클러스터에 설치되며 워크로드 클러스터에도 배포할 준비가 되어 있습니다.
Dex 자체 외에도 이 앱은 Dex를 통해 인증된 클러스터에 대해 kubectl 구성하는 데 도움이 되는 Dex K8s 인증자를 제공합니다.
이 앱을 설치하는 방법에는 여러 가지가 있습니다.
사용자 정의 values.yaml 파일을 통해 구성을 제공합니다. 다음은 Azure Active Directory용 커넥터를 사용하는 예입니다. 더 많은 커넥터 예는 아래에서 확인할 수 있습니다.
isWorkloadCluster : true
services :
kubernetes :
api :
caPem : |
-----BEGIN CERTIFICATE-----
M...=
-----END CERTIFICATE-----
oidc :
expiry :
signingKeys : 6h
idTokens : 30m
customer :
connectors :
- id : customer
connectorName : test
connectorType : microsoft
connectorConfig : |-
clientID: <CLIENT-ID-SET-IN-YOUR-IdP>
clientSecret: <CLIENT-SECRET-SET-IN--YOUR-IdP>
tenant: <TENANT-SET-SET-IN--YOUR-IdP>
redirectURI: https://dex.<CLUSTER>.<BASEDOMAIN>/callback몇 가지 참고사항:
.service.kubernetes.api.caPem 은 PEM 형식의 워크로드 클러스터의 CA 인증서입니다. Giant Swarm에서는 워크로드 클러스터에 대한 클라이언트 인증서를 생성할 때 kubectl gs login 명령을 통해 이 인증서를 검색할 수 있습니다. kubectl 구성 파일에서 Base46으로 인코딩된 형식으로 끝납니다. Dex K8s 인증에는 CA 인증서가 필요합니다.
커넥터 구성의 redirectURI 에는 Dex 자체 수신에 대한 적절한 호스트 이름이 포함되어야 합니다. 기본 형식에는 워크로드 클러스터 이름( <CLUSTER> 실제 이름으로 대체)과 기본 도메인( <BASEDOMAIN> 적절한 기본 도메인으로 대체)이 포함됩니다.
두 개 이상의 커넥터를 구성하는 경우 각 커넥터에 대해 고유한 id 설정해야 합니다. 이 Dex 버전은 모든 사용자 그룹 이름 앞에 커넥터 ID가 붙도록 구성되어 있습니다. 따라서 커넥터의 id customer 인 경우 그룹 devops 의 멤버십은 customer:devops 로 표시됩니다.
Keycloak의 커넥터 구성 예:
- id : customer
connectorName : test
connectorType : oidc
connectorConfig : |-
clientID: <CLIENT-ID-SET-IN-YOUR-IdP>
clientSecret: <CLIENT-SECRET-SET-IN--YOUR-IdP>
insecureEnableGroups: true
scopes:
- email
- groups
- profile
issuer: https://<IDP_ENDPOINT>/auth/realms/master
redirectURI: https://dex.<CLUSTERID>.<BASEDOMAIN>/callbackGitHub용 커넥터 구성 예:
- id : customer
connectorName : test
connectorType : github
connectorConfig : |-
clientID: <CLIENT-ID-SET-IN-YOUR-IdP>
clientSecret: <CLIENT-SECRET-SET-IN--YOUR-IdP>
loadAllGroups: false
teamNameField: slug
orgs:
- name: <GITHUB_ORG_NAME>
teams:
- <GITHUB_TEAM_SLUG>
redirectURI: https://dex.<CLUSTERID>.<BASEDOMAIN>/callback메모:
<GITHUB_ORG_NAME> 은 GitHub 조직 이름입니다. 예를 들어 https://github.com/myorg 의 myorg 부분입니다.<GITHUB_TEAM_SLUG> 는 팀 이름을 나타내는 팀 URL의 일부입니다. 예를 들어 https://github.com/orgs/myorg/teams/my-team 의 my-team 부분입니다. 앱은 앱 플랫폼을 통해 워크로드 클러스터에 설치됩니다. 그렇게 하기 전에 해당 워크로드 클러스터 이름을 딴 네임스페이스에 다음 ConfigMap 리소스를 생성하여 values.yaml 파일의 콘텐츠를 제공하십시오.
apiVersion : v1
kind : ConfigMap
metadata :
name : dex-app-user-values
namespace : <CLUSTER>
data :
values : |
<content of values.yaml>그런 다음 웹 UI를 통해 앱을 설치하거나 다음 형식으로 앱 리소스를 생성합니다.
apiVersion : application.giantswarm.io/v1alpha1
kind : App
metadata :
labels :
app.kubernetes.io/name : dex-app
name : dex-app
namespace : <CLUSTER>
spec :
catalog : giantswarm-playground
name : dex-app
namespace : dex
userConfig :
configMap :
name : <CONFIGMAPNAME>
namespace : <CLUSTER>참고:
<CONFIGMAPNAME> 위에 표시된 ConfigMap 리소스의 이름으로 바꿔야 합니다.<CLUSTER> 는 워크로드 클러스터의 이름으로 대체됩니다.결과적으로 워크로드 클러스터에 Dex가 배포된 것을 볼 수 있습니다.
Dex 앱은 https를 통해 액세스할 수 있는 웹 인터페이스를 노출합니다. 따라서 브라우저에서 신뢰해야 하는 인증 기관에서 서명한 TLS 인증서로 구성해야 하는 수신을 생성합니다. 앱은 https를 통해 내부적으로 서로 통신할 수 있어야 하는 여러 구성 요소로 구성됩니다. 따라서 인증서에 서명하는 인증 기관은 개별 앱 구성 요소에서도 신뢰를 받아야 합니다.
사용자 정의 인증 기관을 사용하는 경우 개별 앱 구성 요소에 노출되고 신뢰할 수 있는 것으로 설정되어야 합니다. 그렇지 않으면 구성 요소가 서로 통신할 수 없고 앱이 예상대로 작동하지 않을 수 있습니다. 클러스터 설정에 따라 앱 구성에 추가 값 세트를 제공하여 이를 달성할 수 있습니다.
ingress :
tls :
letsencrypt : false
caPemB64 : " base64-encoded CA certificate " ingress :
tls :
letsencrypt : false
trustedRootCA :
name : " name-of-the property-in-the-secret "
secretName : " name-of-the-custom-ca-secret "letsencrypt 비활성화하면 dex-tls 라는 비밀이 생성되고 사용자가 제공한 b64 인코딩 값으로 전파됩니다. 또는 사용자가 직접 이 비밀 생성을 관리하고 다음과 같이 사용하도록 설정할 수 있습니다. ingress :
tls :
letsencrypt : false
externalSecret :
enabled : true 그런 다음 실행 중인 네임스페이스 dex 에 다음 비밀을 적용해야 합니다.
apiVersion : v1
kind : Secret
type : kubernetes.io/tls
metadata :
name : dex-tls
data :
ca.crt : ...
tls.crt : ...
tls.key : ...Dex에 대한 트래픽이 프록시를 통과해야 하는 경우(예: 앱이 비공개 클러스터에 설치된 경우) 프록시를 사용하도록 앱의 개별 구성 요소를 설정해야 합니다.
프록시 설정은 앱 구성과 함께 사용자 값 configmap 또는 secret의 특정 섹션에서 앱에 제공될 수 있습니다.
cluster :
proxy :
http : " https://proxy.host:4040 " # hostname of the proxy for HTTP traffic
https : " https://proxy.host:4040 " # hostname of the proxy for HTTPS traffic
noProxy : " kubernetes-api-ip-range " # comma-separated list of hostnames and IP ranges, whose traffic should not go through the proxy. # Kubernetes API IP range needs to be defined here in order for Dex to work correctly 사전 정의된 몇 가지 정적 클라이언트 외에도 Dex 앱은 사용자 정의 정적 클라이언트를 정의할 수 있는 가능성도 지원합니다. extraStaticClients 라는 구성 yaml 파일의 특정 속성에서 객체 배열로 정의되어야 합니다. 각 사용자 정의 정적 클라이언트 객체의 구조는 업스트림 Dex와 정확히 동일합니다.
extraStaticClients :
- id : " client-id "
secret : " client-secret "
trustedPeers :
- " https://example.com "
public : true
name : " client-name-1 "
logoURL : " https://example.com/logo "
- idEnv : " CLIENT_ID "
secretEnv : " CLIENT_SECRET "
redirectURIs :
- " https://example.com/redirect "
name : " client-name-2 "참고:
id 및 idEnv 속성은 상호 배타적입니다.secret 및 secretEnv 속성은 상호 배타적입니다.nameid 또는 idEnvsecret 또는 secretEnv추가 정적 클라이언트를 사전 정의된 정적 클라이언트의 신뢰할 수 있는 피어로 구성할 수도 있습니다.
사전 정의된 정적 클라이언트의 trustedPeers 목록에 추가 정적 클라이언트 ID를 추가합니다.
staticClients :
dexK8SAuthenticator :
clientAddress : " dex.installation.basedomain.io "
clientSecret : " default-client-dex-authenticator-secret "
trustedPeers :
- " client-id "
extraStaticClients :
- id : " client-id "
name : " client-name-1 "
secret : " client-secret "동일한 구성이 생성됩니다.
staticClients :
- id : dex-k8s-authenticator
name : dex-k8s-authenticator
secret : default-client-dex-authenticator-secret
trustedPeers :
- client-id
- id : client-id
name : client-name-1
secret : client-secret
public : true추가 신뢰할 수 있는 피어의 ID가 자동으로 미리 채워진 신뢰할 수 있는 피어 ID와 동일한 경우 중복이 방지됩니다.
Giant Swarm은 현재 원래 프로젝트의 포크에서 dex 앱을 구축하고 있습니다. 사용자 그룹에 커넥터 ID를 접두사로 추가하는 추가 논리를 구현합니다. 이 차트에 사용된 이미지를 업데이트하려면 현재 포크 저장소에서 다음 단계를 수행해야 합니다.
그런 다음 이 저장소에서:
values.yaml 을 변경하는 경우 모든 값과 해당 유형을 올바르게 반영하도록 values.schema.json 이 업데이트되는지 확인하세요.master#release#v<major.minor.patch> 브랜치를 생성하고 해당 릴리스 PR이 생성될 때까지 기다린 후 승인하고 병합합니다.
