이 페이지에서는 Kubernetes 연산자용 MongoDB 컨트롤러로 관리하는 MongoDB Search 및 벡터 검색 배포서버에 대해 소스 데이터를 가져와 복제 상태를 읽기 위해 이 (또는)에 열는 mongot 연결에 대해 설명합니다. mongod mongos 이 연결에서는 mongot 이 클라이언트이고 mongod 가 서버입니다. 이 페이지에서는 mongot 가 mongod (SCRAM 또는 X.509)에 대해 인증하는 방법, 인증에 필요한 역할, 및 mongot 가 TLS를 통해 mongod 서버 인증서를 신뢰하는 방법에 대해 설명합니다.
애플리케이션 사용자는 mongot 에 직접 연결하지 않습니다. 반대 방향(연결이 mongod 이 mongot의 수신 서버에 열리는 연결)의 경우 MongoDB에서 검색으로의 연결 보안을 참조하십시오.
이 페이지에서 참조되는 각 MongoDBSearch 설정의 완전한 스키마를 확인하려면 MongoDB Search 및 벡터 검색 설정을 참조하십시오.
mongot 이 mongod에 대해 인증하는 방법
mongot 이 mongod에 연결하면 상호 배타적 두 가지 모드 중 하나를 사용하여 데이터베이스 클라이언트로 인증합니다.
모드 | 자격 증명 | 다음 경우 사용: |
|---|---|---|
SCRAM | 사용자 이름 및 비밀번호 |
|
X.509 | 클라이언트 인증서 | 조직은 클러스터 서비스를 위해 PKI에서 인증서를 프로비저닝하거나 컴플라이언스 요구 사항이 비밀번호보다 인증서 기반 인증을 선호합니다. |
MongoDBSearch 리소스를 업데이트하고 Kubernetes Operator가 mongot 팝을 다시 시작하도록 하여 배포 후에 모드를 전환할 수 있습니다. mongot 가 인증하는 mongod측 신원이 다음 섹션에 설명된 필요한 역할을 가지고 있는 경우 변경할 필요가 없습니다.
참고
SCRAM에서 X.509 으로 전환하려면 동기화 소스에 TLS가 필요합니다. Kubernetes 연산자는 소스 mongod 가 TLS를 실행하지 않을 경우 X.509 을 거부합니다. 첫 번째 검색 TLS를 활성화하면 원활한 재시작이 아니라 잠시적이지만 실제 쿼리 장애가 발생합니다. 이러한 전환을 수행할 때 잠시적인 중단을 계획하세요. 이동 행동에 대한 자세한 내용은 MongoDB에서 검색으로의 연결 보안 을 참조하세요.
mongod에 필요한 역할 mongot
mongot 이 사용하는 모드에 관계없이 인증하는 신원에게는 mongod에서 데이터를 가져오고 검색 카탈로그를 유지할 수 있는 권한이 있어야 합니다. 이 자격 증명에는 MongoDB Server 8.2 및 이후 버전에 포함되어 있으며 mongot 에 필요한 권한만 부여하는 내장 searchCoordinator 역할이 있어야 합니다.
항상 이 인스턴스를 직접 만듭니다. MongoDBSearch 컨트롤러는 사용자를 위해 이를 만들지 않습니다. 만드는 방법은 Kubernetes 연산자가 소스 mongod를 managed 하는지 여부에 따라 달라집니다.
연산자 managed source.
searchCoordinator역할을 가진 사용자를 선언하고 Community의MongoDBCommunity리소스의users목록에서 암호Secret를 참조하거나 Enterprise의 별도MongoDBUser리소스로 참조합니다. Kubernetes Operator는mongod에 사용자를 프로비저닝합니다. 그 다음mongot이 인증할 수 있도록MongoDBSearch리소스에서 동일한 사용자와Secret를 참조합니다.외부 소스. 사용자를 만들고 자체
mongod배포서버에 대하여searchCoordinator역할을 직접 부여한 다음 아래에 나와 있는 것처럼MongoDBSearch리소스에서 자격 증명을 참조합니다.
이 페이지의 나머지 부분에서는 MongoDBSearch 리소스에서 각 인증 모드를 구성하는 방법과 TLS를 통해 mongod 서버 인증서를 신뢰하는 방법을 설명합니다.
SCRAM 인증 구성
mongot 이(u)가 mongod에 인증하는 데 사용해야 하는 비밀번호가 포함된 Kubernetes Secret 를 제공합니다. spec.source.passwordSecretRef를 통해 MongoDBSearch 리소스에 시크릿을 참조하고 spec.source.username를 통해 사용자 이름을 설정합니다.
spec: source: username: search-sync-source passwordSecretRef: name: my-mongot-password
참조된 Secret 에는 기본적으로 password 이라는 키 아래에 비밀번호가 포함되어 있어야 합니다. 비밀번호를 다른 키 아래에 저장하는 경우 spec.source.passwordSecretRef.key 를 통해 키를 재정의합니다.
spec.source.username 으로 식별된 사용자는 mongod 에 이미 존재해야 하며 searchCoordinator 역할을 가지고 있어야 합니다. spec.source.username을 생략하면 Kubernetes Operator는 사용자 이름이 search-sync-source이라고 가정합니다.
SCRAM 위에 네트워크 계층 mTLS를 추가하려면 클라이언트 인증서와 개인 키가 포함된 Kubernetes Secret 를 제공하고 spec.source.tls.clientCertificateSecretRef를 통해 참조합니다. Secret 에는 tls.crt 과 tls.key가 포함되어 있어야 합니다. Kubernetes 연산자는 사용자 이름과 비밀번호를 통해 계속 인증하면서 TLS 핸드쉐이크 동안 이 인증서를 제시합니다.
spec: source: username: search-sync-source passwordSecretRef: name: my-mongot-password tls: clientCertificateSecretRef: name: my-mongot-client-cert
클라이언트 개인 키가 암호화된 경우 별도의 Secret 에 암호구를 제공하고 spec.source.tls.keyFilePasswordSecretRef를 통해 참조합니다. Secret 에는 keyFilePassword 키에 암호구가 포함되어 있어야 합니다.
X.509 인증을 구성합니다.
X.509 인증은 사용자 이름과 비밀번호 대신 클라이언트 인증서를 통해 mongot 을 mongod 에게 식별합니다. 인증서의 주체 고유 이름(DN)은 mongod에서 mongot의 식별이 됩니다.
참고
spec.source.x509 의 경우 spec.source.username 및 spec.source.passwordSecretRef과 상호 배타적입니다. 두 개 모두 설정하면 Kubernetes 연산자가 MongoDBSearch 리소스를 거부합니다.
tls.crt 및 tls.key 키 아래에 클라이언트 인증서와 개인 키가 포함된 Kubernetes Secret 를 제공하고 spec.source.x509.clientCertificateSecretRef를 통해 MongoDBSearch 리소스에서 참조합니다.
spec: source: x509: clientCertificateSecretRef: name: my-mongot-x509-cert
클라이언트 개인 키가 암호화된 경우 keyFilePassword 키 아래의 별도 Secret 에 암호 구를 제공하고 spec.source.x509.keyFilePasswordSecretRef를 통해 참조하세요.
spec: source: x509: clientCertificateSecretRef: name: my-mongot-x509-cert keyFilePasswordSecretRef: name: my-mongot-key-password
클라이언트 인증서만으로는 액세스가 허용되지 않습니다. mongod 은 인증서의 고유 이름을 승인된 신원으로 인식해야 합니다. 위에서 인증서 시크릿을 만든 후, 다음에 설명된 대로 mongod 에서 해당 인증서의 고유 이름을 승인합니다.
X.509 주제 고유 이름을 승인합니다. mongod
mongod 측에서 위에서 프로비저닝한 클라이언트 인증서의 주제 고유 이름과 일치하는 이름의 $external 데이터베이스에 사용자를 만들고 해당 사용자에 searchCoordinator 역할을 부여합니다. mongod 은 X.509 등 외부 메커니즘을 통해 인증하는 인덴티티를 추적하기 위해 $external 데이터베이스를 사용합니다. Kubernetes Operator가 관리하는 배포서버에서 X.509 사용자를 만들려면 X.509를 사용한 보안 클라이언트 인증을 참조하십시오.
mongod 배포에서도 TLS를 활성화하고 mongot 클라이언트 인증서에 서명한 CA(인증서 발급 기관)를 신뢰하도록 구성해야 합니다. 이는 MongoDBSearch 리소스가 아니라 mongod 배포 자체에서 MongoDB 또는 MongoDBCommunity 리소스를 통해 구성합니다. managed mongod 배포에서 TLS를 활성화하려면 보안 단일 클러스터 클라이언트 연결(TLS/SSL)를 참조하세요.
mongod 서버 인증서 신뢰
위 설정은 mongot의 신원을 확립합니다. 별도로 소스 mongod 가 TLS를 사용하는 경우 mongot 는 mongot 가 연결할 때 mongod 가 제시하는 인증서를 신뢰해야 합니다. mongot 는 이 연결의 TLS 클라이언트이며, mongod 는 서버 인증서를 제시하고 mongot 는 제공하는 CA에 대해 인증서를 검증합니다.
소스 mongod 가 Kubernetes 연산자 외부에 있는 경우(즉, spec.source.external을 통해 선언된 경우)에는 mongod 서버 인증서를 발급한 CA를 제공합니다.
spec: source: external: hostAndPorts: - mongod-0.example.com:27017 tls: ca: name: my-external-mongod-ca
spec.source.external.tls.ca.name 필드는 ca.crt 키 아래에 CA 인증서가 포함된 Kubernetes ConfigMap 를 참조합니다. CA는 mongod 서버 인증서를 발급한 인증서여야 합니다.
소스 mongod 가 Kubernetes Operator(spec.source.mongodbResourceRef 통해) 에 의해 managed되는 경우 Kubernetes Operator가 이 CA 신뢰를 처리하므로 spec.source.external.tls.ca.name 필드가 적용되지 않습니다.
인증서 회전
mongot 프로세스 스타트업 시 클라이언트 인증서를 읽습니다. 인증서를 로테이션하려면 MongoDBSearch 리소스에서 spec.source.x509.clientCertificateSecretRef (X.509 인 경우) 또는 spec.source.tls.clientCertificateSecretRef (SCRAM 위에서의 mTLS 인 경우)에 의해 참조되는 Secret 를 업데이트합니다. Kubernetes Operator는 변경 사항을 감지하고 mongot 팝을 자동으로 다시 시작하여 새 인증서 자료를 로드합니다. 동일한 사항이 spec.source.passwordSecretRef에 의해 참조되는 SCRAM 비밀번호 Secret 에도 적용됩니다.
MCK에서 X.509 클라이언트 인증서를 로테이트하려면:
자동 회전은 MongoDBSearch CRD를 통해 구성할 수 없습니다. 회전을 트리거하려면 spec.source.x509.clientCertificateSecretRef 가 참조하는 Secret 을 업데이트하십시오. Kubernetes Operator가 팝을 자동으로 다시 시작합니다.