OCP4 구성:2.Identity Providers/HTPasswd/LDAP 인증

Modern IT Story
17 min readApr 16, 2021

--

Red Hat OpenShift Container Platform 4 Configuration의 이전 Authentication 내용과 연속된 교육 내용을 정리한 것입니다. 이전글을 참고하지 않으신 분은 이전글을 먼저 참고해 주세요. 그리고 여기에 수록된 내용에 대한 최신 정보는 공식 Red Hat 기술 문서를 참고하세요.

Module Topics

  • Authentication
  • Identity Providers
  • HTPasswd Authentication
  • LDAP Authentication
  • Troubleshooting
<이미지 출처> Red Hat OpenShift Homepage

지원되는 Identity Providers

HTPasswd

클러스터 내에 저장된 htpasswd 암호 데이터베이스에 대한 사용자 이름, 암호의 유효성을 검사

LDAP

단순 바인드 인증을 사용하여 LDAPv3 서버에 대해 사용자 이름, 비밀번호를 검증

Basic authentication (remote)

서버 간 기본 인증 요청을 사용하여 원격 서버에 대해 사용자 이름, 암호를 확인

GitHub

GitHub 또는 GitHub Enterprise OAuth 인증 서버로 인증

GitLab

GitLab 또는 모든 GitLab 인스턴스로 인증

Google

Google의 OpenID Connect 통합을 사용하여 인증

Keystone

OpenStack Keystone v3 서버로 인증

Basic

원격 ID 공급자에 대한 기본 인증으로 인증

OpenID Connect

OpenID 인증 코드 흐름을 지원하는 모든 서버로 인증

Request Header

X-Remote-User 헤더를 사용하여 인증 프록시로 인증

#이 모듈에서는 HTPasswd 및 LDAP 인증에 대해 설명합니다.

HTPasswd Authentication

HTPasswd Identity Provider 개요

  • HTPasswd는 클러스터에 저장된 암호로 인증을 지원함
  • 클러스터 내에 비밀로 저장된 암호 해시
    - openshift-config 네임 스페이스에 구성된 암호
    - htpasswd 형식으로 저장된 비밀번호

htpasswd Secret Creation

  1. Create empty htpasswd file:
touch htpasswd

* touch 명령어 : 리눅스에서 파일을 생성하거나 갱신하는 명령어

2. htpasswd명령을 사용하여 htpasswd 파일의 각 사용자에 대한 암호를 추가합니다.

htpasswd -Bb htpasswd USER PASSWORD

3. openshift-config네임 스페이스의 htpasswd파일에서 htpasswd 비밀을 만듭니다.

oc create secret generic htpasswd --from-file=htpasswd -n openshift-config
2.1. Create HTPasswd Secret 실습 결과 예시 화면

HTPasswd ID 공급자로 클러스터 OAuth 구성

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
name: cluster
spec:
identityProviders:
- name: Local Password
mappingMethod: claim
type: HTPasswd
htpasswd:
fileData:
name: htpasswd

웹 콘솔에서 로그인을 시도 할 때 ID 공급자 이름 (이 예에서 “Local Password”)이 사용자에게 제공됩니다. htpasswd.fileData.namehtpasswd 시크릿 이름을 참조하며이 이름을 가진 시크릿은 openshift-config 프로젝트 네임 스페이스에 있어야합니다.

Updating Passwords in htpasswd Secret

1. 현재 htpasswd 비밀 콘텐츠를 htpasswd 파일에 Dump합니다.

oc get secret htpasswd -n openshift-config -o jsonpath={.data.htpasswd} \
| base64 -d >htpasswd

2. 사용자 비밀번호 추가 또는 업데이트 :

htpasswd -Bb htpasswd USER PASSWORD

3. 파일의 내용으로 htpasswd 비밀 데이터를 Patch합니다.

oc patch secret htpasswd -n openshift-config \
-p '{"data":{"htpasswd":"'$(base64 -w0 htpasswd)'"}}'
2.2 HTPasswd 및 테스트 용 OAuth Identity Provider 구성 실습 결과
위에서 생성한 bob 계정으로 접속 후 화면(bob 계정으로는 Projects가 없음)

LDAP Authentication

LDAP Identity Provider Overview

LDAP는 일반적인 ID 및 액세스 관리 (IAM) 구성 요소임

  • 사용자 ID 및 암호와 함께 중앙 인증 구성 요소로 자주 사용됨

LDAP 인증 단계 :

  • 제공된 사용자 이름을 검색하여 LDAP에서 사용자 ID를 쿼리함
    - 검색 결과 정확히 하나의 항목이 반환되지 않으면 액세스 거부
  • 찾은 사용자 ID 및 사용자가 제공 한 암호를 사용하여 인증을 시도함
    - 인증이 성공하면 구성된 속성을 사용하여 ID를 빌드함

LDAP TLS Security

LDAP 인증에 항상 보안 통신을 사용하는 가장 좋은 방법

  • 특별히 비활성화하지 않는 한 TLS는 ldap://또는 ldaps:// 연결을 사용
  • LDAP TLS 보안에는 TLS 인증 기관 (CA) 인증서가 필요함
  • LDAP TLS 보안 비활성화는 가능하지만 권장하지 않음

LDAP TLS Certificate Authority ConfigMap

LDAP ID 공급자가 사용하려면 LDAP CA 인증서를 ConfigMap에 저장해야함 :

  • CA ConfigMap은 openshift-config네임 스페이스에 있어야 함
  • ConfigMap의 데이터 키는 ca.crt여야합니다.
  • ca.crt데이터 키를 사용하여 openshift-config 프로젝트 네임 스페이스에서 ConfigMap을 만들려면 :
oc create configmap ldap-tls-ca -n openshift-config \
--from-file=ca.crt=PATH_TO_LDAP_CA_FILE

Example OAuth Configuration for LDAP Identity Provider

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
name: cluster
spec:
identityProviders:
- name: OpenTLC LDAP
challenge: true
login: true
mappingMethod: claim
type: LDAP
ldap:
attributes:
id: ["dn"]
email: ["mail"]
name: ["cn"]
preferredUsername: ["uid"]
bindDN: "uid=admin,cn=users,cn=accounts,dc=shared,dc=example,dc=com"
bindPassword:
name: ldap-bind-password
insecure: false
ca:
name: ldap-tls-ca
url: "ldaps://ipa.example.com:636/cn=users,cn=accounts,dc=shared,dc=example,dc=com?uid?sub?(memberOf=cn=ocp-users,cn=groups,cn=accounts,dc=shared,dc=example,dc=com)"
3.1 Configure LDAP TLS Certificate Authority ConfigMap and Bind Password Secret 실습 결과

LDAP 연결 구성(Field : 설명)

ldap.url : LDAP user search URL in format

ldap://host:port/basedn?attribute?scope?filter

ldap.ca.name : LDAP 서버 인증서의 유효성을 검사하기위한 TLS 인증 기관이 있는 ca.crt 데이터 키가 포함 된 OpenShift ConfigMap 이름

ldap.insecure : If = true, LDAP 연결에 사용되는 TLS 보안이 없습니다. ldap.url에서 ldaps:// URL을 사용하는 경우 이러한 URL은 항상 TLS를 사용하여 연결을 시도하므로 false로 설정합니다.

ldap.bindDN : LDAP 사용자 검색 바인드에 대한 인증을 수행하기 위한 LDAP 바인드 사용자 DN

ldap.bindPassword.name : LDAP 사용자 검색 바인드를 위한 bindPassword 데이터 키가 있는 OpenShift secret이름

LDAP User Search URL

LDAP user search URL format:

ldap://host:port/basedn?attribute?scope?filter
  • ldap: LDAP protocol; ldap or ldaps
  • host: Hostname for LDAP server
  • port : DAP port; default is 389 for ldap:// URLs, 636 for ldaps://
  • basedn:모든 검색이 시작되는 디렉토리 분기의 DN (디렉토리 트리의 맨 위 또는 디렉토리의 하위 트리)
  • attribute : 검색 할 속성. 목록인 경우 첫 번째 속성만 사용됨. 제공된 속성이 없으면 기본값은 uid
  • scope : 검색 범위 (one 또는 sub). 제공되지 않는 경우 기본적으로 sub가 사용됨
  • filter : 특정 LDAP 그룹에 속한 사용자에 대한 액세스를 제한하는 데 자주 사용되는 LDAP 검색 필터. 기본값은 (objectClass=*)임.

LDAP User Attribute Configuration

ldap.attributes.email:이메일 주소로 사용할 속성 목록; 비어 있지 않은 첫 번째 속성이 사용됨

ldap.attributes.id : ID로 사용할 속성 목록; 비어 있지 않은 첫 번째 속성이 사용되었음. 하나 이상의 속성이 필요함. 나열된 속성 중 값이없는 경우 인증이 실패함

ldap.attributes.name: 표시 이름으로 사용할 속성 목록; 비어 있지 않은 첫 번째 속성이 사용됨

ldap.attributes.preferredUsername : 이 ID에 대한 사용자를 프로비저닝 할 때 기본 사용자 이름으로 사용할 속성 목록; 비어 있지 않은 첫 번째 속성이 사용되었음

3.2. Configure and Test LDAP Identity Provider 실습

  1. $ HOME / oauth-config.yaml 파일을 편집하고 다음 설정을 사용하여 LDAP identity provider 구성을 추가합니다.
apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
name: cluster
spec:
identityProviders:
- name: Local Password
mappingMethod: claim
type: HTPasswd
htpasswd:
fileData:
name: htpasswd
- name: OPENTLC LDAP
challenge: true
login: true
mappingMethod: claim
type: LDAP
ldap:
attributes:
email: ["mail"]
id: ["dn"]
name: ["cn"]
preferredUsername: ["uid"]
bindDN: "uid=admin,cn=users,cn=accounts,dc=shared,dc=example,dc=opentlc,dc=com"
bindPassword:
name: opentlc-ipa-bind-password
insecure: false
ca:
name: opentlc-ipa-tls-ca
url: "ldaps://ipa.shared.example.opentlc.com:636/cn=users,cn=accounts,dc=shared,dc=example,dc=opentlc,dc=com?uid?sub?(memberOf=cn=ocp-users,cn=groups,cn=accounts,dc=shared,dc=example,dc=opentlc,dc=com)"

2. oauth-config.yaml 파일에서 OAuth 구성을 LDAP 버전으로 바꿉니다.

oc --user=admin replace -f oauth-config.yaml
3.2. Configure and Test LDAP Identity Provider 1) ~ 3)까지 실습 결과

3. 웹 콘솔 URL을 다시 검색하고 웹 브라우저로 돌아갑니다.

4.오른쪽 상단에서 사용자 이름을 클릭 한 다음 로그 아웃을 클릭하여 로그 아웃합니다.

로그인 방식이 OPENTLC LDAP 버튼이 추가 활성화됨

5. LDAP andrew 사용자 및r3dh4t1! 암호를사용하여 OPENTLC LDAP ID 공급자를 사용하여 로그인을 테스트합니다.

LDAP 버튼 선택 후 LDAP에 등록된 사용자 ID/PW로 로그인
우측 상단 화면에 해당 사용자로 접속 확인

6. API URL을 검색하고 karla 사용자로 로그인을 테스트합니다.

7. 생성 된 항목을 동적으로 보려면 사용자 및 해당 ID를 나열합니다.

3.2. Configure and Test LDAP Identity Provider 6) ~ 7)까지 실습 결과

Disable kubeadmin Account

kubeconfig 설치 프로그램 파일을 사용하여 system : admin 계정으로 직접 액세스 할 수 있으므로 kubeadmin 계정이 클러스터에서 활성화 될 필요가 없습니다. 이 섹션에서는 암호 시크릿을 제거하여 kubeadmin 계정을 비활성화합니다.

  1. kube-system 네임 스페이스에서 kubeadmin 시크릿을 삭제하십시오.
$ oc --user=admin delete secret kubeadmin -n kube-system
secret "kubeadmin" deleted

2. kubeadmin 사용자가 더 이상 액세스 할 수 없는지 확인하십시오.

$ API_URL=$(oc whoami --show-server)
$ KUBEADMIN_PASSWORD="$(cat $HOME/cluster-$GUID/auth/kubeadmin-password)"
$ oc login -u kubeadmin -p "$KUBEADMIN_PASSWORD" "$API_URL"
Login failed (401 Unauthorized)
Verify you have provided correct credentials.

3. TLS 인증을 사용하여 system:admin account계정을 계속 사용할 수 있는지 확인합니다.

$ oc --user=admin whoami
system:admin

Troubleshooting

system:admin User

system:admin user bypasses OAuth authentication

  • system:admin 콘솔 로그인을 사용할 수 없음
  • TLS 인증서로 수행되는 인증
  • 초기 설치 중에 생성된 kubeconfig 파일에 저장된 TLS 자격 증명
  • 복구를 위해 초기 kubeconfig 파일의 사본을 안전한 위치에 저장

To use system:admin:

$ export KUBECONFIG=OCP4_INSTALL_DIR/auth/kubeconfig
$ oc config use-context admin
Switched to context "admin".
$ oc whoami
system:admin

Authentication Logs

  • OpenShift OAuth pod logs
  • List pods in openshift-authentication namespace—for example:
$ oc get pods -n openshift-authentication
oauth-openshift-8fcd5c679-f82qx 1/1 Running 0 142m
oauth-openshift-8fcd5c679-tkpcl 1/1 Running 0 142m
  • Check pod logs of each oauth-openshift pod—for example:
$ oc logs -n openshift-authentication oauth-openshift-8fcd5c679-f82qx
$ oc logs -n openshift-authentication oauth-openshift-8fcd5c679-tkpcl

Openshift authentication operator logs

  • Operator is pod found in openshift-authentication-operator project namespace
    - Check operator logs:
oc logs -n openshift-authentication-operator deployment/authentication-operator

User and Identity Resources

처음 로그인 할 때 생성 된 사용자 및 ID 리소스

  • Get user resources: oc get users
  • Get identity resources: oc get identities

동적으로 생성 된 사용자 및 ID 레코드는 사용자 이름 충돌시 오류를 생성:

  • oauth-openshift pod logs indicate AuthenticationError: user "USERNAME" cannot be claimed by identity "IDENTITY" because it is already mapped to [CURRENT_IDENTITY]” Local Passwords:jkupfere]
  • OAuth 재구성 후 오류가 발생하면 사용자 및 ID를 삭제해야 할 수 있습니다.
  • 사용자 및 ID 리소스가 삭제되고 다음 로그인시 다시 생성 될 때 RBAC가 보존 됨

ID 레코드에 저장된 LDAP email, namepreferred_username 속성

이어서 다음글을 참고하세요.

> Next : 3. Group Management

< Previous : 1.Authentication

--

--

Modern IT Story
Modern IT Story

Written by Modern IT Story

Certified Architect, Hybrid Cloud

No responses yet