복제본 세트를 키 파일 인증으로 업데이트(다운타임 없음)

사용자 관리자를 만듭니다.

프라이머리 에 연결하여 userAdminAnyDatabase 역할을 가진 사용자를 만듭니다. userAdminAnyDatabase 역할은 배포의 모든 데이터베이스에서 사용자 생성에 대한 액세스 권한을 부여합니다.

다음 예에서는 admin 데이터베이스에 userAdminAnyDatabase 역할을 가진 fred 사용자를 만듭니다.

admin = db.getSiblingDB("admin")
admin.createUser(
  {
    user: "fred",
    pwd: " passwordPrompt(),     // or cleartext password
    roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
  }
)

이 절차가 완료되면 복제본 세트의 사용자를 관리하는 모든 클라이언트는 이 사용자 또는 유사한 권한을 가진 사용자로 인증해야 합니다.

기본 제공 역할 및 데이터베이스 관리 작업과 관련된 역할의 전체 목록은 데이터베이스 사용자 역할에서 확인하세요.

클러스터 관리자를 만듭니다.

프라이머리 에 연결하여 clusterAdmin 역할을 가진 사용자를 만듭니다. clusterAdmin 역할은 복제본 세트 구성과 같은 복제 작업에 대한 액세스 권한을 부여합니다.

다음 예에서는 admin 데이터베이스에 clusterAdmin 역할을 가진 ravi 사용자를 만듭니다.

db.getSiblingDB("admin").createUser(
  {
    "user" : "ravi",
    "pwd" :  passwordPrompt(),     // or cleartext password
    roles: [ { "role" : "clusterAdmin", "db" : "admin" } ] 
  }
)

이 절차가 완료되면 복제본 세트를 관리하거나 유지 관리하는 모든 클라이언트는 해당 사용자 또는 유사한 권한을 가진 사용자로 인증해야 합니다.

복제본 세트 작업과 관련된 기본 제공 역할의 전체 목록은 클러스터 관리 역할에서 확인하세요.

클라이언트 애플리케이션에 대한 사용자를 생성합니다.

클라이언트 애플리케이션이 복제본 세트에 연결하고 상호 작용할 수 있도록 사용자를 생성합니다. 이 튜토리얼을 완료하면 클라이언트는 구성된 사용자로 인증해야 복제본 세트에 연결할 수 있습니다.

읽기 전용 및 읽기/쓰기 사용자를 생성할 때 활용할 수 있는 기본 제공 역할은 데이터베이스 사용자 역할에서 확인하세요.

다음은 foo 데이터베이스에 대해 읽기 및 쓰기 권한이 있는 사용자를 생성합니다.

foo 데이터베이스에서 readWrite 역할을 가진 사용자를 생성합니다.

db.getSiblingDB("foo").createUser(
  {
    "user" : "joe",
    "pwd" :  passwordPrompt(),     // or cleartext password
    roles: [ { "role" : "readWrite", "db" : "foo" } ] 
  }
)

이 사용자로 인증하는 클라이언트는 foo 데이터베이스에 대해 읽기 및 쓰기 작업을 수행할 수 있습니다. 복제본 세트에 대한 인증된 연결 생성에 대한 자세한 내용 은 사용자 인증을 참조하세요.

사용자 추가에 대한 자세한 내용은 사용자 추가 튜토리얼을 참조하세요. 새 사용자를 추가할 때는 보안 권장 사항을 고려하세요.

클라이언트 애플리케이션 업데이트

절차의 이 점에서 복제본 세트는 인증을 시행하지 않습니다. 그러나 클라이언트 애플리케이션은 여전히 인증 자격 증명을 지정하고 복제본 세트에 연결할 수 있습니다.

구성된 사용자를 사용하여 복제본 세트에 인증하도록 클라이언트 애플리케이션을 업데이트합니다. 인증된 연결에는 사용자 이름, 비밀번호 및 인증 데이터베이스가 필요합니다. 사용자 인증을 참조하세요.

예를 들어, 다음은 복제본 세트 이름 mongoRepl 에 연결하고 사용자 joe로 인증합니다.

mongosh  -u joe -password  -authenticationDatabase foo --host mongoRepl/mongo1.example.net:27017, mongo2.example.net:27017, mongo3.example.net:27017

-p 명령줄 옵션에 비밀번호를 지정하지 않으면 mongosh 에서 비밀번호를 입력하라는 메시지를 표시합니다.

애플리케이션에서 MongoDB 드라이버를 사용하는 경우 인증된 연결 생성에 대한 지침은 관련 드라이버 설명서를 참조하세요.

이 튜토리얼을 완료하면 복제본 세트는 인증되지 않은 클라이언트 연결을 거부합니다. 이제 이 단계를 수행하면 전환 전후에 클라이언트가 복제본 세트에 연결할 수 있습니다.

키 파일을 생성합니다.

키 파일 인증을 사용하면 복제본 세트의 각 mongod 인스턴스는 배포서버에서 다른 멤버를 인증하기 위한 공유 암호로 키 파일의 내용을 사용합니다. 올바른 키 파일을 가진 mongod 인스턴스만 복제본 세트에 참여할 수 있습니다.

키 길이는 6~1024자 사이여야 하며, base64 세트의 문자만 포함할 수 있습니다. 복제본 세트의 모든 멤버는 하나 이상의 공통 키를 공유해야 합니다.

원하는 방법을 사용하여 키 파일을 생성할 수 있습니다. 예를 들어 다음 작업에서는 openssl 사용하여 공유 암호로 사용할 복잡한 의사 난수 1024자 문자열을 생성합니다. 그런 다음 chmod 사용하여 파일 소유자에게만 읽기 권한을 제공하도록 파일 권한을 변경합니다.

openssl rand -base64 756 > <path-to-keyfile>
chmod 400 <path-to-keyfile>

키파일 사용에 대한 추가 세부 정보 및 요구 사항은 키파일을 참조하세요.

각 복제본 세트 멤버에 키 파일을 복사합니다.

복제본 세트 멤버를 호스팅하는 각 서버에 키 파일을 복사합니다. mongod 인스턴스를 실행하는 사용자가 파일의 소유자이며 키 파일에 액세스할 수 있도록 합니다.

USB 드라이브 또는 네트워크 연결 저장 장치와 같이 mongod 인스턴스를 호스팅하는 하드웨어에서 쉽게 분리될 수 있는 저장 매체에 키 파일을 저장하지 마세요.

transitionToAuth 를 사용하여 복제본 세트의 각 세컨더리 또는 중재자 멤버를 다시 시작합니다.

구성을 포함하여 복제본 세트의 각 세컨더리 또는 중재자 멤버를 다시 시작합니다.

• security.transitionToAuth 설정. mongod security.transitionToAuth 가 로 설정된 true 상태에서 를 시작하면 인스턴스가 인증된 연결과 인증되지 않은 연결을 모두 허용하고 생성할 수 있는 전환 상태가 됩니다.

• security.keyFile 과 같은 내부 인증 메커니즘입니다.

복제본 세트에 있는 멤버의 대부분이 온라인 상태를 유지하려면 각 멤버를 한 번에 하나씩 재시작해야 합니다.

admin = db.getSiblingDB("admin")
admin.shutdownServer()

security:
  keyFile: <path-to-keyfile>
  transitionToAuth: true
replication:
  replSetName: <replicaSetName>

mongod 을(를) 시작할 때 구성 파일 경로와 함께 --config 옵션을 지정합니다

mongod --config <path-to-config-file>

구성 파일에 대한 자세한 내용은 구성 옵션을 참조하세요.

또는 이에 상응하는 mongod 명령줄 옵션을 사용할 수 있습니다(예: --transitionToAuth 및 --keyFile) mongod. 전체 옵션 목록은 mongod 참고 페이지를 참조하세요.

배포에 적합한 추가 설정을 포함하세요.

이 단계가 끝나면 모든 보조 및 중재자가 로 설정된 security.transitionToAuth true 상태로 실행되어 실행되어야 합니다.

복제본 세트의 프라이머리 멤버를 강등하고 --transitionToAuth 으)로 재시작합니다.

복제본 세트의 프라이머리 멤버를 강등하고 구성을 포함하여 멤버를 다시 시작합니다.

• security.transitionToAuth 설정. mongod security.transitionToAuth 가 로 설정된 true 상태에서 를 시작하면 인스턴스가 인증된 연결과 인증되지 않은 연결을 모두 허용하고 생성할 수 있는 전환 상태가 됩니다.

• security.keyFile 과 같은 내부 인증 메커니즘입니다.

rs.stepDown()

admin = db.getSiblingDB("admin")
admin.shutdownServer()

security:
  keyFile: <path-to-keyfile>
  transitionToAuth: true
replication:
  replSetName: <replicaSetName>
  

구성 파일을 사용하여 mongod 을(를) 시작합니다.

mongod --config <path-to-config-file>

구성 파일에 대한 자세한 내용은 구성 옵션을 참조하세요.

또는 이에 상응하는 mongod 명령줄 옵션을 사용할 수 있습니다(예: --transitionToAuth 및 --keyFile) mongod. 전체 옵션 목록은 mongod 참고 페이지를 참조하세요.

배포에 적합한 추가 설정을 포함하세요.

이 단계가 끝나면 security.transitionToAuth 을 true 로, security.keyFile 를 키 파일 경로로 설정하여 복제본 세트의 모든 멤버를 가동해야 합니다.

--transitionToAuth 없이 세컨더리 및 중재자를 다시 시작합니다.

복제본 세트의 각 세컨더리 또는 중재자 멤버를 재시작하고 재시작 시 security.transitionToAuth 옵션을 제거합니다. 복제본 세트에 있는 대부분의 멤버가 온라인 상태를 유지하려면 이 작업을 한 번에 하나씩 수행해야 합니다.

복제본 세트 구성원의 대부분이 동시에 오프라인 상태인 경우 복제본 세트는 Go 읽기 전용 모드로 전환될 수 있습니다.

admin = db.getSiblingDB("admin")
admin.shutdownServer()

security:
  keyFile: <path-to-keyfile>
replication:
  replSetName: <replicaSetName>

구성 파일을 사용하여 mongod를 시작합니다.

mongod --config <path-to-config-file>

구성 파일에 대한 자세한 내용은 구성 옵션을 참조하세요.

을(를) 시작할 때 mongod 이에 상응하는 mongod 옵션을 사용할 수도 있습니다. 전체 옵션 목록은 mongod 참고 페이지를 참조하세요.

배포에 적합한 추가 설정을 포함하세요.

이 단계가 끝나면 모든 보조 및 중재자가 내부 인증이 구성된 상태로 실행되고 실행되어야 하지만 security.transitionToAuth 이 없어야 합니다. 클라이언트는 구성된 클라이언트 인증 메커니즘을 통해서만 이러한 mongod 인스턴스에 연결할 수 있습니다.

--transitionToAuth 없이 프라이머리 복제본 세트 멤버를 강등했다가 다시 시작합니다.

복제본 세트의 프라이머리 멤버를 강등한 다음 security.transitionToAuth 옵션 없이 재시작합니다.

rs.stepDown()

admin = db.getSiblingDB("admin")
admin.shutdownServer()

security:
  keyFile: <path-to-keyfile>
replication:
  replSetName: <replicaSetName>
  

구성 파일을 사용하여 mongod를 시작합니다.

mongod --config <path-to-config-file>

구성 파일에 대한 자세한 내용은 구성 옵션을 참조하세요.

mongod를 시작할 때 이에 상응하는 mongod 옵션을 사용할 수도 있습니다. 전체 옵션 목록은 mongod 참고 페이지를 참조하세요.

배포에 적합한 추가 설정을 포함하세요.

이 단계가 끝나면 복제본 세트의 모든 구성원이 인증이 시행된 상태에서 실행 중이어야 합니다. 클라이언트는 구성된 클라이언트 인증 메커니즘을 통해서만 이러한 mongod 인스턴스에 연결할 수 있습니다.