x의 롤링 업데이트. 자체 관리형 클러스터에 새 DN이 포함된 509 인증서
이 페이지의 내용
복제본 세트 또는 샤딩된 클러스터 의 구성원은 멤버십 인증 에x.509 인증서를 사용하여 동일한 배포서버 내 다른 서버를 식별할 수 있습니다.
서버 노드 연결 요청 받으면 제공된 인증서의 subject 필드 에 있는 고유 이름(DN) 속성을 자체 인증서의 주체 DN 속성과 비교합니다. 인증서의 주체에 조직(O), 조직 단위(OU) 및 도메인 구성 요소(DC) 속성에 대해 동일한 값이 포함되어 있는 경우 인증서가 일치합니다. 서버의 구성 파일 매개변수에서 일치에 사용할 대체 DN 속성을 지정할 수도 있습니다.tlsX509ClusterAuthDNOverride 서버의 주체 DN 속성 또는 구성된 값이 제시된 인증서의 주체 DN 속성과 일치하는 경우 서버 노드 연결을 클러스터 구성원으로 tlsX509ClusterAuthDNOverride 취급합니다.
조직 이 이름을 변경하는 경우와 같이 일부 상황에서는 구성원 인증서를 새 주체 고유 이름(DN) 속성이 있는 새 인증서로 업데이트 해야 할 수 있습니다. 롤링 업데이트 에서는 구성원 인증서가 한 번에 하나씩 업데이트되며 배포서버 다운타임이 발생하지 않습니다.
새 인증서를 채택하는 클러스터는 매개 tlsX509ClusterAuthDNOverride 변수를509 사용하여 인증서 순환 절차 중에 주체 DN 속성이 다른 x. 인증서를 수락할 수 있습니다. 모든 구성원이 새 값의 인증서를 사용하면 재정의를 제거 오래된 인증서 거부를 시작합니다.
이 작업에 관한 정보
509 clusterFile 및 설정을 certificateKeyFile 사용하여 "OU=10gen Server,O=10gen" 설정하다 각 구성원의 x. 인증서에 주체 DN 속성이 인 복제본 세트 가 있다고 가정해 보겠습니다.
이 복제본 세트 의 멤버에는 다음과 같은 구성 파일 있습니다.
net.tls.mode: requireTLS net.tls.certificateKeyFile: "./mycerts/10gen-server1.pem" net.tls.CAFile: "./mycerts/ca.pem" security.clusterAuthMode: x509 net.tls.clusterFile: "./mycerts/10gen-cluster1.pem" net.tls.clusterCAFile: "./mycerts/ca.pem"
다음 절차에서는 각 구성원의 인증서를 주체 DN 속성이 "OU=MongoDB Server, O=MongoDB"인 새 인증서로 업데이트합니다.
참고
다음 절차에서는 새 x.509 인증서가 멤버십 인증서 및 기타 모든 요구 사항을 충족하고 클러스터 구성이 고유 이름(DN) 값을 사용하여 피어 인증서를 식별한다고 가정합니다. 자세한 내용은 멤버 인증서 요구 사항을 참조하세요.
단계
모든 멤버에 대해 재정의 매개변수를 설정합니다.
롤링 업데이트 중에는 새 구성으로 한 번에 한 명씩 멤버가 다시 시작됩니다. 이전 주체 DN 속성을 가진 서버 노드가 새 주체 DN 속성을 가진 노드를 클러스터 멤버로 식별할 수 있도록 하려면 실행 모든 멤버에서 재정의 매개변수를 새 주체 DN 속성으로 설정하다 .
이렇게 하려면 각 서버 의 구성 파일 수정하여 tlsX509ClusterAuthDNOverride 새 인증서의 주체 DN 속성을 사용하도록 매개 변수를 설정하다 .
net.tls.mode: requireTLS net.tls.certificateKeyFile: "./mycerts/10gen-server1.pem" net.tls.CAFile: "./mycerts/ca.pem" security.clusterAuthMode: x509 net.tls.clusterFile: "./mycerts/10gen-cluster1.pem" net.tls.clusterCAFile: "./mycerts/ca.pem" setParameter: tlsX509ClusterAuthDNOverride: "OU=MongoDB Server,O=MongoDB"
이 구성은 각 멤버를 다시 시작할 때까지 고려되지 않습니다.
모든 멤버를 다시 시작합니다.
모든 멤버의 롤링 재시작 수행하려면 각 세컨더리 재시작한 다음 프라이머리 재시작합니다.
각 세컨더리 멤버에 대해 mongosh 를 멤버에 연결한 후 다음을 수행합니다.
db.shutdownServer()메서드를 사용하여 멤버를 종료합니다:use admin db.shutdownServer() 멤버를 다시 시작합니다.
다음 세컨더리 다시 시작하기 전에 이 멤버가
SECONDARY상태 에 도달했는지 확인합니다. 멤버 상태rs.status()확인하려면stateStr를 실행 필드 의 값을 읽습니다.rs.status().members
프라이머리멤버의 경우 를 멤버에 mongosh 연결한 후 다음을 수행합니다.
rs.stepDown()를 사용하여 멤버를 물러나게 합니다:rs.stepDown() db.shutdownServer()메서드를 사용하여 멤버를 종료합니다:use admin db.shutdownServer() 멤버를 다시 시작합니다.
이제 복제본 세트 의 모든 서버는 재정의 매개변수를 사용하여 새 주체 DN 속성이 있는 인증서를 사용하는 구성원의 피어 연결을 수락할 수 있습니다.
모든 멤버의 구성을 수정합니다.
각 서버의 구성 파일을 업데이트합니다.
net.tls.certificateKeyFile설정을 새 인증서로 변경합니다.net.tls.clusterFile설정을 새 인증서로 변경합니다.이전 인증서의 고유 이름 속성을 사용하려면
tlsX509ClusterAuthDNOverride매개변수를 설정합니다.
예를 들면 다음과 같습니다.
net.tls.mode: requireTLS net.tls.certificateKeyFile: "./mycerts/mongodb-server1.pem" net.tls.CAFile: "./mycerts/ca.pem" security.clusterAuthMode: x509 net.tls.clusterFile: "./mycerts/mongodb-cluster1.pem" net.tls.clusterCAFile: "./mycerts/ca.pem" setParameter: tlsX509ClusterAuthDNOverride: "OU=10Gen Server,O=10Gen"
이 구성은 각 멤버를 다시 시작할 때까지 고려되지 않습니다.
모든 멤버를 다시 시작합니다.
업데이트된 구성을 각 멤버에 적용 하려면 2 단계의 절차를 반복하여 서버 노드의 롤링 재시작 수행합니다.
이 프로세스 중에 새 인증서로 다시 시작된 노드는 에 저장된 이전 DN 속성을 사용하여 이전 인증서를 제공하는 노드를 tlsX509ClusterAuthDNOverride 식별합니다. 아직 이전 인증서가 있는 노드는 에 저장된 새 DN을 사용하여 새 인증서를 제공하는 노드를 tlsX509ClusterAuthDNOverride 식별합니다.
모든 멤버에서 재정의 매개변수를 제거합니다.
업데이트된 서버 노드가 이전 인증서를 제시하는 클라이언트를 피어로 취급하지 않도록 하려면 모든 서버 노드 구성 파일에서 tlsX509ClusterAuthDNOverride 매개 변수를 제거 .
예를 들면 다음과 같습니다.
net.tls.mode: requireTLS net.tls.certificateKeyFile: "./mycerts/mongodb-server1.pem" net.tls.CAFile: "./mycerts/ca.pem" security.clusterAuthMode: x509 net.tls.clusterFile: "./mycerts/mongodb-cluster1.pem" net.tls.clusterCAFile: "./mycerts/ca.pem"
이 구성은 각 멤버를 다시 시작할 때까지 고려되지 않습니다.