자체 관리형 클러스터에서 X.509 인증서 로테이션

이 페이지의 내용

이 작업에 관한 정보

단계
자세히 알아보기

버전 7.0에 추가.

클러스터 구성원은 구성원 인증 에 X.509 인증서를 사용하여 동일한 배포서버 에 있는 다른 서버를 식별할 수 있습니다.

서버는 연결 요청을 수신하면 인증서의 고유 이름(DN) 값 또는 확장 값 문자열을 clusterAuthX509 설정 및 tlsClusterAuthX509Override 매개변수의 구성된 값과 비교합니다. 값이 일치하면 연결을 cluster 멤버로 취급합니다.

새 인증서를 채택하는 cluster는 tlsClusterAuthX509Override 매개 변수를 사용하여 인증서 순환 절차 중에 다른 DN 속성을 가진 X.509 인증서를 수락할 수 있습니다. 모든 구성원이 새 값으로 인증서를 사용하면 재정의를 제거하여 이제 오래된 인증서 거부를 시작합니다.

참고

net.tls.clusterAuthX509 설정을 사용하지 않고 업데이트 이후에 사용하지 않는 클러스터 에서 인증서를 순환시키기 위해 롤링 업데이트 를 수행하려면 x의 롤링 업데이트 를 참조하세요.509 자체 관리형 클러스터에 새 DN이 포함된 인증서.

이 작업에 관한 정보

회원 인증서( clusterFile 및 certificateKeyFile 설정을 사용하여 설정)에 10gen 조직 및 10gen Server 조직 단위( attributes 설정을 사용하여 설정)를 사용하는 고유 이름(DN) 값이 있는 복제본 세트를 생각해 보세요.

security:
  clusterAuthMode:      x509
net:
  tls:
    mode:               requireTLS
    certificateKeyFile: /etc/mycerts/10gen-server1.pem
    CAFile:             /etc/mycerts/ca.pem
    clusterFile:        /etc/mycerts/10gen-cluster1.pem
    clusterCAFile:      /etc/mycerts/ca.pem
    clusterAuthX509:
       attributes:      O=10gen, OU=10gen Server

이 튜토리얼에서는 새 X.509 인증서가 멤버십 인증서 및 기타 모든 요구 사항을 충족하고 클러스터 구성이 고유 이름(DN) 값을 사용하여 피어 인증서를 식별한다고 가정합니다.

자세한 내용은 회원 인증서 요구 사항을 참조하세요.

단계

이 단계에서는 attributes 설정으로 구성된 cluster에서 새 X.509 인증서를 사용하도록 멤버 인증서를 업데이트합니다.

새 인증서에는 조직(O) 속성을 10gen 에서 MongoDB 로, 조직 단위(OU) 속성을 10gen Server 에서 MongoDB Server 로 변경하는 고유 이름(DN)이 있습니다.

TLS 클러스터 멤버십 구성 업데이트

각 서버의 구성 파일을 업데이트합니다.

새 인증서의 값을 사용하도록 attributes 설정을 변경합니다.
이전 인증서의 고유 이름 속성을 사용하려면 tlsClusterAuthX509Override 매개변수를 설정합니다.

예를 들면 다음과 같습니다.

net:
  tls:
    mode:               requireTLS
    certificateKeyFile: /etc/mycerts/mongodb-server1.pem
    CAFile:             /etc/mycerts/ca.pem
    clusterFile:        /etc/mycerts/mongodb-cluster1.pem
    clusterCAFile:      /etc/mycerts/ca.pem
    clusterAuthX509:
       attributes:      O=MongoDB, OU=MongoDB Server
security:
  clusterAuthMode: x509
setParameter:
   tlsClusterAuthX509Override: { attributes: O=10gen, OU=10gen Server }

보조 cluster 멤버 다시 시작

각 세컨더리 cluster 멤버를 다시 시작합니다:

mongosh 를 사용하여 각 세컨더리 클러스터 멤버에 연결한 다음, db.shutdownServer() 메서드를 사용하여 서버를 중지합니다.
```
use admin
db.shutdownServer()
```
서버를 다시 시작합니다.
rs.status() 메서드를 사용하여 멤버 상태를 확인합니다.
```
rs.status().members
```
이 멤버의 stateStr 필드에 SECONDARY 값이 표시될 때까지 기다렸다가 다음 세컨더리를 다시 시작하세요.

이제 복제본 세트의 세컨더리 서버가 새 DN 속성이 있는 인증서를 사용하여 구성원의 피어 연결을 허용합니다.

프라이머리 cluster 멤버 재시작

프라이머리 멤버를 다시 시작합니다.

mongosh 을 사용하여 프라이머리에 연결한 다음 rs.stepDown() 메서드를 사용하여 멤버를 프라이머리로 강등합니다.
```
rs.stepDown()
```
cluster는 새 인증서로 보조 인증서를 새 프라이머리 역할을 하도록 승격합니다.
db.shutdownServer() 메서드를 사용하여 서버를 종료합니다:
```
use admin
db.shutdownServer()
```
서버를 다시 시작합니다.

복제본 세트의 프라이머리 서버는 강등되고 이제 새 DN 속성이 있는 인증서를 사용하여 구성원의 Peering 연결을 허용하는 세컨더리 서버로 다시 시작됩니다.

TLS 인증서 업데이트

각 서버의 구성 파일을 업데이트합니다.

새 인증서를 사용하도록 net.tls.certificateKeyFile 설정을 변경합니다.
새 인증서를 사용하도록 net.tls.clusterFile 설정을 변경합니다.

예를 들면 다음과 같습니다.

net:
  tls:
    mode:               requireTLS
    certificateKeyFile: /etc/mycerts/mongodb-server2.pem
    CAFile:             /etc/mycerts/ca.pem
    clusterFile:        /etc/mycerts/mongodb-cluster2.pem
    clusterCAFile:      /etc/mycerts/ca.pem
    clusterAuthX509:
       attributes:      O=MongoDB, OU=MongoDB Server
security:
  clusterAuthMode: x509
setParameter:
   tlsClusterAuthX509Override: { attributes: O=10gen, OU=10gen Server }

보조 cluster 멤버 다시 시작

각 세컨더리 cluster 멤버를 다시 시작합니다:

mongosh 를 사용하여 각 세컨더리 클러스터 멤버에 연결한 다음, db.shutdownServer() 메서드를 사용하여 서버를 중지합니다.
```
use admin
db.shutdownServer()
```
서버를 다시 시작합니다.
rs.status() 메서드를 사용하여 멤버 상태를 확인합니다.
```
rs.status().members
```
이 멤버의 stateStr 필드에 SECONDARY 값이 표시될 때까지 기다렸다가 다음 세컨더리를 다시 시작하세요.

이제 복제본 세트의 세컨더리 서버가 새로운 X.509 인증서를 사용합니다.

프라이머리 cluster 멤버 재시작

프라이머리 멤버를 다시 시작합니다.

mongosh 을 사용하여 프라이머리에 연결한 다음 rs.stepDown() 메서드를 사용하여 멤버를 프라이머리로 강등합니다.
```
rs.stepDown()
```
cluster는 새 인증서로 보조 인증서를 새 프라이머리 역할을 하도록 승격합니다.
db.shutdownServer() 메서드를 사용하여 서버를 종료합니다:
```
use admin
db.shutdownServer()
```
서버를 다시 시작합니다.

복제본 세트의 프라이머리 서버는 강등되고 새 X.509 인증서를 사용하는 세컨더리 서버로 다시 시작됩니다.

고유 이름 인증 재정의 구성 제거

이제 cluster의 모든 멤버가 새 X.509 인증서를 사용하므로 구성 setParameter tlsClusterAuthX509Override 파일을 업데이트하여 매개 변수에 대한 설정을 제거합니다.

예를 들면 다음과 같습니다.

net:
  tls:
    mode:               requireTLS
    certificateKeyFile: /etc/mycerts/mongodb-server1.pem
    CAFile:             /etc/mycerts/ca.pem
    clusterFile:        /etc/mycerts/mongodb-cluster1.pem
    clusterCAFile:      /etc/mycerts/ca.pem
    clusterAuthX509:
       attributes:      O=MongoDB, OU=MongoDB Server
security:
  clusterAuthMode: x509

이렇게 하면 서버가 시작 시 이전 인증서 설정을 구성하지 않습니다.

보조 cluster 멤버 다시 시작

각 세컨더리 cluster 멤버를 다시 시작합니다:

mongosh 를 사용하여 각 세컨더리 클러스터 멤버에 연결한 다음, db.shutdownServer() 메서드를 사용하여 서버를 중지합니다.
```
use admin
db.shutdownServer()
```
서버를 다시 시작합니다.
rs.status() 메서드를 사용하여 멤버 상태를 확인합니다.
```
rs.status().members
```
이 멤버의 stateStr 필드에 SECONDARY 값이 표시될 때까지 기다렸다가 다음 세컨더리를 다시 시작하세요.

복제본 세트의 세컨더리 서버가 다시 시작되고 더 이상 이전 X.509 인증서에서의 연결을 허용하지 않습니다.

프라이머리 cluster 멤버 재시작

프라이머리 멤버를 다시 시작합니다.

mongosh 을 사용하여 프라이머리에 연결한 다음 rs.stepDown() 메서드를 사용하여 멤버를 프라이머리로 강등합니다.
```
rs.stepDown()
```
cluster는 새 인증서로 보조 인증서를 새 프라이머리 역할을 하도록 승격합니다.
db.shutdownServer() 메서드를 사용하여 서버를 종료합니다:
```
use admin
db.shutdownServer()
```
서버를 다시 시작합니다.

프라이머리 서버는 더 이상 이전 X.509 인증서에서의 연결을 허용하지 않는 세컨더리 서버로 다시 시작됩니다.

자세히 알아보기

돌아가기

새 DN으로 x.509 업데이트

Use x.509 Extension Values