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

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

Connect to the 기본 to create a user with userAdminAnyDatabase role. The userAdminAnyDatabase role grants access to user creation on any database in the deployment.

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

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

At the completion of this procedure, any client that administers users in the replica set must authenticate as this user, or a user with similar permissions.

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

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

Connect to the 기본 to create a user with clusterAdmin role. The clusterAdmin role grants access to replication operations, such as configuring the replica set.

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

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

At the completion of this procedure, any client that administrates or maintains the replica set must authenticate as this user, or a user with similar permissions.

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

Create users for client applications.

Create users to allow client application to connect and interact with the replica set. At the completion of this tutorial, clients must authenticate as a configured user to connect to the replica set.

See 데이터베이스 사용자 역할 for basic built-in roles to use in creating read-only and read-write users.

The following creates a user with read and write permissions on the foo database.

Create a user with the readWrite role in the foo database.

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

Clients authenticating as this user can perform read and write operations against the foo database. See 자체 관리형 배포로 사용자 인증 for more on creating an authenticated connection to the replica set.

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

Update Client Applications

At this point in the procedure, the replica set does not enforce authentication. However, client applications can still specify auth credentials and connect to the replica set.

Update client applications to authenticate to the replica set using a configured user. Authenticated connections require a username, password, and the authentication database. See 자체 관리형 배포로 사용자 인증.

For example, the following connects to a replica set named mongoRepl and authenticates as the user joe.

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

-p 명령줄 옵션에 비밀번호를 지정하지 않으면 mongosh(이)가 비밀번호를 묻는 메시지를 표시합니다.

If your application uses a MongoDB driver, see the associated 드라이버 documentation for instructions on creating an authenticated connection.

At the completion of this tutorial, the replica set rejects non-authenticated client connections. Performing this step now ensures clients can connect to the replica set before and after the transition.

키 파일을 생성합니다.

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

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

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

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

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

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

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

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

Restart each secondary or arbiter member of the replica set with transitionToAuth.

Restart each 보조 or 중재자 member in the replica set, including in the configuration:

• The security.transitionToAuth setting. Starting the mongod with security.transitionToAuth set to true places the instance in a transition state where it can accept and create both authenticated and non-authenticated connections.

• An internal authentication mechanism such as security.keyFile.

You must restart each member one at a time to ensure a majority of members in the replica set remain online.

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

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

Specify the --config option with the path to the configuration file when starting the mongod.

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

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

Alternatively, you can use the equivalent mongod command-line options (e.g. --transitionToAuth and --keyFile) when starting your mongod. See the mongod reference page for a complete list of options.

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

At the end of this step, all secondaries and arbiters should be up and running with security.transitionToAuth set to true.

Step down the primary member of the replica set and restart it with --transitionToAuth.

Step down the 기본 member in the replica set and restart the member, including in its configuration:

• The security.transitionToAuth setting. Starting the mongod with security.transitionToAuth set to true places the instance in a transition state where it can accept and create both authenticated and non-authenticated connections.

• An internal authentication mechanism such as security.keyFile.

rs.stepDown()

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

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

Start the mongod using the configuration file.

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

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

Alternatively, you can use the equivalent mongod command-line options (e.g. --transitionToAuth and --keyFile) when starting your mongod. See the mongod reference page for a complete list of options.

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

At the end of this step, all members of the replica set should be up and running with security.transitionToAuth set to true and security.keyFile set to the keyfile path.

Restart secondaries and arbiters without --transitionToAuth

Restart each 보조 or 중재자 member in the replica set, removing the security.transitionToAuth option on restart. You must do this one at a time to ensure a majority of members in the replica set remain online.

If the majority of replica set members are offline at the same time, the replica set may go into read-only mode.

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

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

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

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

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

You can also use the equivalent mongod options when starting your mongod. See the mongod reference page for a complete list of options.

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

At the end of this step, all secondaries and arbiters should be up and running with internal authentication configured, but without security.transitionToAuth. Clients can only connect to these mongod instances by using the configured client authentication mechanism.

Step down and restart the primary replica set member without --transitionToAuth.

Step down the 기본 member in the replica set, then restart it without the security.transitionToAuth option.

rs.stepDown()

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

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

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

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

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

You can also use the equivalent mongod options when starting your mongod. See the mongod reference page for a complete list of options.

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

At the end of this step, all members of the replica set should be up and running with authentication enforced. Clients can only connect to these mongod instances by using the configured client authentication mechanism.