OIDC를 사용한 보안 클라이언트 인증

Kubernetes Operator는 인증 메커니즘 으로 OIDC(OpenID Connect)를 지원합니다. OIDC 인증 구성하면 클라이언트 애플리케이션은 MongoDB 리소스 에 JSON web token (JSON web token )을 제공합니다. MongoDB 구성된 OIDC ID 제공자(IdP)에 대해 JSON web token 유효성을 검사하고 토큰 내의 클레임을 사용하여 사용자의 ID와 선택적으로 역할 매핑을 위한 그룹 멤버십을 확인합니다.

이 가이드 Kubernetes Operator를 사용하여 MongoDB deployment에 연결하는 클라이언트 애플리케이션에 대해 OIDC 인증 구성하는 방법을 설명합니다.

참고

Kubernetes 클러스터 에서는 OIDC로 MongoDB 의 독립형 인스턴스를 보호할 수 없습니다.

고려 사항

OIDC 인증 활성화 때는 다음 사항을 고려하세요.

ID 제공자: 기존에 구성된 OIDC ID 제공자(IdP)가 있어야 합니다. Kubernetes Operator는 IdP 자체를 관리 하지 않습니다.
권한 부여: Kubernetes Operator는 OIDC를 통해 인증 (ID 확인)을 구성합니다. 권한 부여(권한 부여)는 OIDC 클레임을 MongoDB 사용자 지정 리소스 내의 MongoDB 역할에 매핑하여 처리됩니다.
페더레이션: MongoDB는 Workload Identity Federation(머신 간 인증의 경우)과 Workforce Identity Federation(인간 사용자 인증의 경우)을 모두 지원합니다.
TLS 암호화: 보안을 강화하려면 TLS로 암호화된 복제본 세트 또는 TLS로 암호화된 샤딩된 클러스터 배포 것이 좋습니다. ID 제공자 와의 OIDC 통신은 HTTPS로 보호되지만, MongoDB 리소스 에서 TLS를 활성화하면 클라이언트 애플리케이션 과 데이터베이스 간의 연결이 암호화됩니다. 이렇게 하면 네트워크 위협으로부터 OIDC 토큰과 기타 모든 데이터베이스 트래픽을 보호할 수 있습니다.

일반 전제 조건

MongoDB deployment에 대한 OIDC 인증 구성하기 전에 다음 작업을 완료하세요.

MongoDB 엔터프라이즈 데이터베이스 리소스 배포 해야 합니다. MongoDB Community 데이터베이스는 OIDC 인증 지원 하지 않습니다.
복제본 세트 배포 하거나 OpenID Connect로 보호하려는 클라이언트 인증 있는 샤딩된 클러스터 배포.

OIDC 구성 세부 정보

필드	유형과 필요성	설명	예시
`spec.security.authentication.modes`	문자열 배열 ; 필수	활성화 인증 메커니즘의 배열 . OIDC 인증 활성화 하려면 'OIDC'를 포함해야 합니다.	`["SCRAM", "OIDC"]`
`spec.security.authentication.oidcProviderConfigs.configurationName`	문자열; 필수	이 제공자 구성에 대한 고유한 논리적 이름입니다. 이 이름은 역할을 매핑할 때 사용됩니다.	`"example-provider"`
`spec.security.authentication.oidcProviderConfigs.issuerURI`	문자열; 필수	OIDC 제공자의 검색 엔드포인트 URI입니다.	`"https://dev-12345.provider.com"`
`spec.security.authentication.oidcProviderConfigs.clientId`	문자열; 필수	OIDC 제공자 에 등록된 애플리케이션 의 클라이언트 ID .	`"0oa1b2c3d4e5f6g7h8"`
`spec.security.authentication.oidcProviderConfigs.audience`	문자열; 필수	JSON web token 에 대한 대상 클레임입니다. 이는 IdP에서 발급한 토큰의 대상과 일치해야 합니다.	`"api://default"`
`spec.security.authentication.oidcProviderConfigs.userClaim`	문자열; 선택 사항	MongoDB 사용자 이름 으로 사용하는 JSON web token 클레임입니다. 기본값은 `sub`입니다.	`"sub"`
`spec.security.authentication.oidcProviderConfigs.groupsClaim`	문자열; 선택 사항	사용자의 그룹 멤버십이 포함된 JSON web token 클레임입니다. `authorizationType` 이 `GroupMembership`인 경우 필수입니다.	`"groups"`
`spec.security.authentication.oidcProviderConfigs.authorizationMethod`	문자열; 필수	페더레이션 메서드. `WorkloadIdentityFederation` 또는 `WorkforceIdentityFederation`일 수 있습니다.	`"WorkforceIdentityFederation"`
`spec.security.authentication.oidcProviderConfigs.authorizationType`	문자열; 필수	권한 부여 모델. `UserID` 또는 `GroupMembership`일 수 있습니다.	`"GroupMembership"`
`spec.security.authentication.oidcProviderConfigs.requestedScopes`	문자열 배열 ; 선택 사항	OIDC 제공자 에게 요청 추가 범위 목록입니다.	`["openid", "profile", "groups"]`

OIDC 권한 부여 모델 이해

MongoDB 의 OIDC 구성은 페더레이션 메서드 와 권한 부여 유형이라는 두 가지 주요 개념을 결합합니다.

페더레이션 메서드(`authorizationMethod`)

이 설정은 인증되는 ID 유형을 MongoDB 알립니다.

WorkforceIdentityFederation: 인간 사용자에게 사용합니다. 이 방법은 IdP를 통해 인증하는 개발자, 분석가 또는 관리자와 같이 시스템에 로그인하는 사람들을 대상으로 합니다.
WorkloadIdentityFederation: 애플리케이션 또는 서비스 (예: 기계 간 통신)에 사용합니다. 이 방법은 데이터베이스 에 연결해야 하는 microservices, 배치 작업 또는 자동화 스크립트 와 같은 사람이 아닌 ID에 사용됩니다.

권한 부여 유형(`authorizationType`)

이 설정은 사용자 또는 서비스가 인증된 후 MongoDB 권한을 부여하는 방법을 정의합니다.

GroupMembership: 가장 일반적이고 확장 가능한 접근 방식입니다. 이 유형을 사용하면 MongoDB 사용자가 속한 그룹 목록이 포함된 JSON web token (groupsClaim으로 정의됨)의 특정 클레임을 사용합니다. 그런 다음 이러한 그룹 이름을 MongoDB 역할에 매핑합니다. groupsClaim 을(를 ) 설정하다 해야 합니다.
UserID: 이 유형을 사용하면 MongoDB 사용자를 고유하게 식별하는 클레임을 사용합니다(userClaim로 정의됨, 기본값은 sub). 그런 다음 이 특정 개별 사용자 ID MongoDBUser에 매핑합니다(MongoDBUser를 별도로 생성해야 함). 이는 더 세분화되어 있으며 그룹을 사용하지 않고 단일 사용자 또는 특정 서비스 ID에 권한을 부여하는 데 유용합니다.

OIDC 역할 및 권한 관리

OIDC 제공자 구성한 후에는 권한을 부여해야 합니다. 이 작업을 수행하는 데 사용하는 방법은 선택한 authorizationType 에 따라 다릅니다.

메서드 1: GroupMembership에 대한 역할 매핑

authorizationType: GroupMembership를 사용하는 경우 MongoDB 리소스 의 spec.security.roles 배열 에 역할 매핑을 추가하여 권한을 부여합니다. 역할 필드 형식은 <configurationName>/<groupNameFromToken>로 지정해야 합니다.

roles:
 - role: "idp-human-users/app-devs" # Maps the "app-devs" group from the IdP
   db: "admin"
   roles:
     - role: "readWrite"
       db: "app-data"

메서드 2: UserID에 대한 사용자 생성

authorizationType: UserID를 사용하는 경우 권한을 부여하려면 별도의 MongoDBUser 리소스 만들어야 합니다.

자세한 학습 은 OIDC/OAuth 2.0을 사용한 인증 및 권한 부여를 참조하세요.

복제본 세트에 대한 OIDC 클라이언트 인증 구성

다음 단계에 따라 복제본 세트 에 대한 OIDC를 구성합니다.

Kubernetes Operator 복제본 세트 정의 파일 조회합니다.

기존 복제본 세트 정의 파일 있는 경우 해당 파일을 엽니다. 또는 아래의 전체 작업 예제를 복사할 수 있습니다.

OIDC 인증 설정을 추가합니다.

정의 파일 에서 spec.security 섹션을 수정합니다. 사용 사례 에 따라 다음 예시 중 하나 이상을 선택합니다. oidcProviderConfigs 배열 에서 여러 제공자 구성을 결합할 수 있습니다.

예시 A: 그룹 멤버십이 있는 Workforce Federation

IdP의 그룹 멤버십을 기반으로 인간 사용자를 인증하는 데 사용합니다. 이는 사용자 팀을 관리하는 가장 일반적인 모델입니다.

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-oidc-replicaset
spec:
  type: ReplicaSet
  members: 3
  version: 7.0.11-ent
  opsManager:
    configMapRef:
      name: <my-project-configmap>
  credentials: <my-credentials-secret>
  security:
    authentication:
      modes: ["SCRAM", "OIDC"]
      oidcProviderConfigs:
        - configurationName: "idp-human-users"
          issuerURI: "https://<your-idp-domain>"
          clientId: "<your-client-id>"
          audience: "api://default"
          groupsClaim: "groups"
          authorizationMethod: "WorkforceIdentityFederation"
          authorizationType: "GroupMembership"
    roles:
      - role: "idp-human-users/app-devs"
        db: "admin"
        roles:
          - role: "readWrite"
            db: "app-data"

예시 B: UserID를 사용한 워크로드 페더레이션

특정 ID로 애플리케이션 또는 서비스를 인증하는 데 사용합니다. 이는 서비스 계정에 이상적입니다.

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-oidc-replicaset
spec:
  type: ReplicaSet
  members: 3
  version: 7.0.11-ent
  opsManager:
    configMapRef:
      name: <my-project-configmap>
  credentials: <my-credentials-secret>
  security:
    authentication:
      modes: ["SCRAM", "OIDC"]
      oidcProviderConfigs:
        - configurationName: "billing-service-auth"
          issuerURI: "https://<your-idp-uri>"
          clientId: "<billing-service-client-id>"
          audience: "mongodb-api"
          userClaim: "sub"
          authorizationMethod: "WorkloadIdentityFederation"
          authorizationType: "UserID"

참고

참고: 이 ID에 대한 권한을 부여하려면 MongoDBUser 리소스 도 만들어야 합니다. 해당 리소스 의 사용자 이름 billing-service-auth/<user-subject-from-jwt>(으)로 설정하다 되어야 합니다.

자세한 학습 은 OIDC 인증을 사용하여 데이터베이스 사용자 관리를 참조하세요.

예시 C: UserID를 사용한 인력 페더레이션

이를 사용하여 특정 인간 사용자에게 그룹 멤버십에 포함되지 않는 고유한 권한을 부여할 수 있습니다.

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-oidc-replicaset
spec:
  type: ReplicaSet
  members: 3
  version: 7.0.11-ent
  opsManager:
    configMapRef:
      name: <my-project-configmap>
  credentials: <my-credentials-secret>
  security:
    authentication:
      modes: ["SCRAM", "OIDC"]
      oidcProviderConfigs:
        - configurationName: "idp-special-user"
          issuerURI: "https://<your-idp-domain>"
          clientId: "<your-client-id>"
          audience: "api://default"
          userClaim: "sub"
          authorizationMethod: "WorkforceIdentityFederation"
          authorizationType: "UserID"

참고

자세한 학습 은 OIDC 인증을 사용하여 데이터베이스 사용자 관리를 참조하세요.

예시 D: 그룹 멤버십이 있는 Workload Federation

모두 동일한 권한이 필요한 관련 서비스 또는 애플리케이션 그룹 인증하는 데 사용합니다.

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-oidc-replicaset
spec:
  type: ReplicaSet
  members: 3
  version: 7.0.11-ent
  opsManager:
    configMapRef:
      name: <my-project-configmap>
  credentials: <my-credentials-secret>
  security:
    authentication:
      modes: ["SCRAM", "OIDC"]
      oidcProviderConfigs:
        - configurationName: "reporting-services"
          issuerURI: "https://<your-idp-uri>"
          clientId: "<reporting-services-client-id>"
          audience: "mongodb-api"
          groupsClaim: "service-roles"
          authorizationMethod: "WorkloadIdentityFederation"
          authorizationType: "GroupMembership"
    roles:
      - role: "reporting-services/report-generators"
        db: "admin"
        roles:
          - role: "read"
            db: "sales-data"

구성을 적용합니다.

kubectl apply -f <your-replica-set-file>.yaml

배포 상태를 추적합니다.

kubectl get mdb <resource-name> -o yaml -w

샤드 클러스터에 대한 OIDC 클라이언트 인증 구성

다음 예시 사용하여 샤딩된 클러스터 에 대한 OIDC를 구성합니다. 원칙과 구성 옵션은 복제본 세트 와 동일합니다.

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-oidc-shardedcluster
spec:
  type: ShardedCluster
  shardCount: 2
  mongodsPerShardCount: 3
  mongosCount: 2
  configServerCount: 3
  version: 7.0.11-ent
  opsManager:
    configMapRef:
      name: <my-project-configmap>
  credentials: <my-credentials-secret>
  security:
    authentication:
      modes: ["SCRAM", "OIDC"]
      oidcProviderConfigs:
        # Provider 1: For human users (Workforce/Group)
        - configurationName: "idp0-human-users"
          issuerURI: "https://<your-idp0-domain>"
          clientId: "<human-users-client-id>"
          audience: "api://default"
          groupsClaim: "groups"
          authorizationMethod: "WorkforceIdentityFederation"
          authorizationType: "GroupMembership"
        # Provider 2: For service accounts (Workload/UserID)
        - configurationName: "service-accounts"
          issuerURI: "https://<your-idp-uri>"
          clientId: "<services-client-id>"
          audience: "mongodb-api"
          userClaim: "sub"
          authorizationMethod: "WorkloadIdentityFederation"
          authorizationType: "UserID"
    roles:
      # Role mapping for the human user group
      - role: "idp0-human-users/db-admins"
        db: "admin"
        roles:
          - role: "readWriteAnyDatabase"
            db: "admin"

OIDC 문제 해결

JSON web token 토큰 수동 유효성 검사: 도구를 사용하여 OIDC 토큰을 디코딩합니다.
- 핵심 클레임: 토큰의 iss (발급자) 및 aud (대상) 클레임이 OIDC 제공자 구성과 정확히 일치하는지 확인합니다. 토큰이 만료되지 않았는지 확인합니다(exp 클레임).
- 예상 사용자/그룹 클레임: 사용자 ID(userClaim) 및 그룹(groupsClaim)에 대한 예상 클레임이 토큰에 있고 올바른 값이 포함되어 있는지 확인합니다.
사용자 ID 인증을 위한 사용자 이름 형식 확인: MongoDBUser 사용자 이름 정확한 <configurationName>/<userClaimValue> 형식이어야 합니다. <configurationName> 는 MongoDB 리소스 에 있는 OIDC 제공자 의 이름과 일치해야 합니다.
$external 데이터베이스 사용 확인: UserID 권한 부여 의 경우 MongoDBUser 리소스 db: "$external"를 지정해야 합니다. 외부 소스에서 인증한 사용자는 항상 이 가상 데이터베이스 통해 확인됩니다.
GroupMembership 인증을 위한 그룹 역할 매핑 확인: MongoDB 리소스의 spec.security.roles 섹션에 정의된 역할 형식이 <configurationName>/<groupName>로 올바르게 지정되어 있는지, 여기서 <groupName> 는 JSON 웹 토큰의 groupsClaim에 있는 그룹 정확히 일치하는지 확인합니다.
할당된 역할 권한 유효성 검사: OIDC 사용자 또는 그룹에 할당된 MongoDB 역할 실제로 필요한 권한(예: 올바른 데이터베이스에 대한 readWrite)을 부여하는지 확인합니다.
MongoDBUser 리소스 참조 확인: UserID 권한 부여 의 경우 MongoDBUser 리소스 의 spec.mongodbResourceRef.name 이(가) MongoDB 배포서버 의 이름을 올바르게 가리키는지 확인합니다.

참고