Docs Menu
Docs Home
/
MongoDB 매뉴얼
/ / / /

자체 관리형 샤딩된 클러스터를 키 파일 인증으로 업데이트(다운타임 없음)

이 페이지의 내용

  • 개요
  • 고려 사항
  • 기존 샤드 cluster에 키 파일 액세스 제어 적용
  • x.509 인증서 내부 인증

중요

다음 절차는 MongoDB 3.4 이상을 사용하는 샤딩된 cluster에 적용됩니다.

이전 버전의 MongoDB 는 다운타임 없는 업그레이드 를 지원 하지 않습니다. 이전 버전의 MongoDB 를 사용하는 샤딩된 클러스터의 경우 자체 관리형 샤드 클러스터를 키 파일 인증으로 업데이트를 참조하세요.

MongoDB cluster는 사용자 인증 과 구성 요소의 내부 인증 을 시행하여 무단 액세스로부터 보호할 수 있습니다.

다음 튜토리얼에서는 security.transitionToAuth 을(를) 사용하여 다운타임 없이 인증을 적용하기 위해 기존 샤드 cluster를 전환하는 절차를 설명합니다.

이 튜토리얼을 시도하기 전에 이 문서의 내용을 숙지하세요.

또는 Cloud Manager Cloud Manager MongoDB Ops Manager를 사용하여 배포를 관리하는 경우 매뉴얼 MongoDB 또는 MongoDB Ops Manager 매뉴얼 에서 배포에 대한 액세스 제어 구성 을 참조하여 인증을 시행하세요.

2} 및mongod mongos MongoDB localhost 바이너리는 기본적으로 에 바인딩됩니다.

이 튜토리얼에서는 클라이언트 인증에는 SCRAM 을 사용하고 내부 인증에는 파일을 사용하여 인증을 구성합니다.

사용 가능한 클라이언트 및 내부 인증 메커니즘의 전체 목록은 자체 관리 배포서버에 대한 인증 문서를 참조하세요.

이 튜토리얼에서는 각 샤드 복제본 세트와 config 서버 복제본 세트가 기존 프라이머리를 한 단계 낮추고 새 프라이머리 를 선택할 수 있다고 가정합니다.

복제본 세트는 다음 조건이 모두 참인 경우에만 프라이머리를 선출할 수 있습니다.

샤드 cluster에 사용 가능한 mongos 인스턴스가 두 개 이상 있는지 확인합니다. 이 튜토리얼에서는 cluster의 각 mongos 를 다시 시작해야 합니다. 샤드 cluster에 mongos 인스턴스가 하나만 있는 경우 mongos 가 오프라인 상태인 동안 다운타임이 발생합니다.

키 파일 인증을 사용하면 샤딩된 클러스터의 각 mongod 또는 mongos 인스턴스는 배포에서 다른 멤버를 인증하기 위한 공유 암호로 키 파일의 내용을 사용합니다. 올바른 키 파일을 가진 mongod 또는 mongos 인스턴스만 샤딩된 클러스터에 참여할 수 있습니다.

참고

내부 멤버십 인증을 위한 키파일은 YAML 형식을 사용해 키파일에 여러 키를 허용합니다. YAML 형식은 다음 중 하나를 허용합니다.

  • 단일 키 문자열(이전 버전과 동일)

  • 키 문자열의 순서

YAML 형식은 텍스트 파일 형식을 사용하는 기존의 단일 키 키파일과 호환됩니다.

키 길이는 6~1024자 사이여야 하며 base64 세트의 문자만 포함할 수 있습니다. 샤딩된 클러스터의 모든 멤버는 하나 이상의 공통 키를 공유해야 합니다.

참고

UNIX 시스템에서는 키 파일에 그룹 또는 월드 권한이 없어야 합니다. Windows 시스템에서는 키 파일 권한이 확인되지 않습니다.

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

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

샤딩된 클러스터 멤버를 호스팅하는 각 서버에 키 파일을 복사합니다. mongod 또는 mongos 인스턴스를 실행하는 사용자가 파일의 소유자이며 키 파일에 액세스할 수 있도록 합니다.

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

내부 인증을 위한 키파일 사용에 대한 자세한 내용은 키파일을 참조 하세요.

이 섹션의 단계를 완료하려면 mongos 에 연결해야 합니다. 이 단계에서 생성된 사용자는 클러스터 수준 사용자이며 개별 샤드 복제본 세트에 액세스하는 데 사용할 수 없습니다.

1

db.createUser() 메서드를 사용하여 관리자 사용자를 만들고 다음 역할을 할당합니다.

샤드 cluster에서 유지 관리 작업 또는 사용자 관리 작업을 수행하는 클라이언트는 이 튜토리얼 완료 시 이 사용자로 인증해야 합니다. 인증을 시행한 후 cluster에 액세스할 수 있도록 하려면 지금 이 사용자를 생성하십시오.

admin = db.getSiblingDB("admin");
admin.createUser(
{
user: "admin",
pwd: "<password>",
roles: [
{ role: "clusterAdmin", db: "admin" },
{ role: "userAdmin", db: "admin" }
]
}
);

중요

악의적인 액세스를 방지하거나 방해할 수 있도록 비밀번호는 임의적이고 길며 복잡해야 합니다.

2

관리자 사용자 외에도 인증을 시행하기 전에 추가 사용자를 생성할 수 있습니다. 이렇게 하면 인증을 완전히 시행한 후에도 샤드 cluster에 대한 액세스가 보장됩니다.

예시

다음 작업은 marketing 데이터베이스에 joe 사용자를 생성하고 이 사용자에게 marketing 데이터베이스에 대한 readWrite 역할을 할당합니다.

db.getSiblingDB("marketing").createUser(
{
"user": "joe",
"pwd": "<password>",
"roles": [ { "role" : "readWrite", "db" : "marketing" } ]
}
)

"joe" 으)로 인증하는 클라이언트는 marketing 데이터베이스에서 읽기 및 쓰기 작업을 수행할 수 있습니다.

MongoDB에서 제공하는 역할은 데이터베이스 사용자 역할 을 참조하세요.

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

3

현재 샤드 cluster는 인증을 시행하지 않지만, 샤드 cluster에 연결할 때 인증 자격 증명을 지정하도록 클라이언트 애플리케이션을 업데이트할 수 있습니다. 이렇게 하면 이 튜토리얼을 완료할 때 연결 끊김을 방지할 수 있습니다.

예시

다음 작업은 mongosh를 사용하여 샤딩된 클러스터에 연결하고 marketing 데이터베이스에서 사용자 joe로 인증합니다.

mongosh --username "joe" --password "<password>" \
--authenticationDatabase "marketing" --host mongos1.example.net:27017

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

1

mongos 대해 다음을 수행합니다.

  1. 기존 mongos 구성 파일을 복사하여 <filename>-secure.conf (또는 Windows를 사용하는 경우 .cfg )와 같은 고유 이름을 지정합니다. 이 새 구성 파일을 사용하여 shard cluster에서 인증을 적용하기 위해 mongos 을(를) 전환합니다. 백업을 위해 원본 구성 파일을 유지합니다.

  2. 새 구성 파일에 다음 설정을 추가합니다.

    • security.transitionToAuth 다음으로 설정 true

    • security.keyFile 키 파일 경로로 설정합니다.

      다른 내부 인증 메커니즘을 사용하는 경우 메커니즘에 적합한 설정을 지정합니다.

    security:
    transitionToAuth: true
    keyFile: <path-to-keyfile>

    새 구성 파일에는 이전에 mongos 에서 사용한 모든 구성 설정과 새 보안 설정이 포함되어 있어야 합니다.

2

참고

cluster에 mongos 가 하나만 있는 경우 이 단계를 수행하면 mongos 이 오프라인 상태일 때 다운타임이 발생합니다.

한 번에 하나씩 mongos mongos 인스턴스를 다시 시작하려면 다음 절차를 따르세요.

  1. 종료하려면 mongos 에 연결합니다.

  2. admin 데이터베이스에 대해 db.shutdownServer() 메서드를 사용하여 mongos 을 안전하게 종료합니다.

    db.getSiblingDB("admin").shutdownServer()
  3. 새 구성 파일로 mongos 를 다시 시작하고 --config 를 사용하여 구성 파일의 경로를 지정합니다. 예를 들어 새 구성 파일의 이름이 mongos-secure.conf 인 경우입니다.

    mongos --config <path>/mongos-secure.conf

    여기서 <path> 은 새 구성 파일이 포함된 폴더의 시스템 경로를 나타냅니다.

샤드 cluster의 mongos 모든 mongos 인스턴스가 다시 시작될 때까지 다음 인스턴스에 대해 다시 시작 프로세스를 반복합니다.

이 섹션의 끝에서는 샤드 cluster의 모든 mongos 인스턴스가 security.transitionToAuthsecurity.keyFile 내부 인증으로 실행 중입니다.

1

config 서버 복제본 세트의 각 mongod 에 대해

  1. 기존 mongod 구성 파일을 복사하여 <filename>-secure.conf (또는 Windows를 사용하는 경우 .cfg )와 같은 고유 이름을 지정합니다. 이 새 구성 파일을 사용하여 shard cluster에서 인증을 적용하기 위해 mongod 을(를) 전환합니다. 백업을 위해 원본 구성 파일을 유지합니다.

  2. 새 구성 파일에 다음 설정을 추가합니다.

    • security.transitionToAuth 다음으로 설정 true

    • security.keyFile 키 파일 경로로 설정합니다.

      다른 내부 인증 메커니즘을 사용하는 경우 메커니즘에 적합한 설정을 지정합니다.

    security:
    transitionToAuth: true
    keyFile: <path-to-keyfile>
2

세컨더리 멤버부터 시작하여 한 번에 한 멤버씩 복제본 세트를 다시 시작합니다.

  1. 세컨더리 멤버를 한 번에 하나씩 다시 시작하려면 다음을 수행합니다.

    1. mongod 에 연결하고 admin 데이터베이스에 대해 db.shutdownServer() 메서드를 사용하여 mongod 을 안전하게 종료합니다.

      db.getSiblingDB("admin").shutdownServer()
    2. 새 구성 파일로 mongod 를 다시 시작하고 { --config 를 사용하여 구성 파일의 경로를 지정합니다. 예를 들어 새 구성 파일의 이름이 mongod-secure.conf 인 경우입니다.

      mongod --config <path>/mongod-secure.conf

      여기서 <path> 은 새 구성 파일이 포함된 폴더의 시스템 경로를 나타냅니다.

    이 멤버가 활성화되면 다음 세컨더리 멤버에 대해 이 과정을 반복합니다.

  2. 모든 세컨더리 멤버가 다시 시작되고 작동되면 프라이머리 멤버를 다시 시작합니다.

    1. mongod 에 연결합니다.

    2. rs.stepDown() 메서드를 사용하여 프라이머리를 물러나고 trigger 투표를 트리거합니다.

      rs.stepDown()

      rs.status() 메서드를 사용하여 복제본 세트가 새 프라이머리를 선택했는지 확인할 수 있습니다.

    3. 프라이머리를 물러나고 새 프라이머리가 선출되면 admin 데이터베이스에 대해 db.shutdownServer() 메서드를 사용하여 이전 프라이머리를 종료합니다.

      db.getSiblingDB("admin").shutdownServer()
    4. 새 구성 파일로 mongod 를 다시 시작하고 { --config 를 사용하여 구성 파일의 경로를 지정합니다. 예를 들어 새 구성 파일의 이름이 mongod-secure.conf 인 경우입니다.

      mongod --config <path>/mongod-secure.conf

      여기서 <path> 은 새 구성 파일이 포함된 폴더의 시스템 경로를 나타냅니다.

이 섹션의 끝에서는 config 서버 복제본 세트의 모든 mongod 인스턴스가 security.transitionToAuthsecurity.keyFile 내부 인증으로 실행 중입니다.

인증을 시행하는 샤드 클러스터에서는 각 샤드 복제본 세트에 자체 샤드 로컬 관리자 가 있어야 합니다. 한 샤드에 대해 샤드 로컬 관리자를 사용하여 다른 샤드 또는 샤드 클러스터에 액세스할 수 없습니다.

각 샤드 복제본 세트의 프라이머리 멤버에 연결하고 db.createUser() 메서드를 사용하여 사용자를 생성하고 다음 역할을 할당합니다.

메서드/명령 호출에서 암호를 직접 지정하는 대신 passwordPrompt() 메서드를 다양한 사용자 인증/관리 메서드/명령과 함께 사용하여 암호를 묻는 메시지를 표시할 수 있습니다. 그러나 이전 버전의 mongo 셸에서와 마찬가지로 비밀번호를 직접 지정할 수도 있습니다.

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

이 튜토리얼을 완료한 후 샤드에 연결하여 샤드에 직접 연결해야 하는 유지 관리 작업을 수행하려면 샤드 로컬 관리자로 인증해야 합니다.

참고

샤드에 대한 직접 연결은 샤드별 유지 관리 및 구성을 위해서만 이루어져야 합니다. 일반적으로 클라이언트는 mongos 를 통해 샤드 cluster에 연결해야 합니다.

한 번에 하나의 샤드 복제본 세트를 전환하는 경우 cluster의 각 복제본 세트에 대해 이 단계를 반복합니다.

1

샤드 복제본 세트의 각 mongod 에 대해

  1. 기존 mongod 구성 파일을 복사하여 <filename>-secure.conf (또는 Windows를 사용하는 경우 .cfg )와 같은 고유 이름을 지정합니다. 이 새 구성 파일을 사용하여 shard cluster에서 인증을 적용하기 위해 mongod 을(를) 전환합니다. 백업을 위해 원본 구성 파일을 유지합니다.

  2. 새 구성 파일에 다음 설정을 추가합니다.

    • security.transitionToAuth 다음으로 설정 true

    • security.keyFile 키 파일 경로로 설정합니다.

      다른 내부 인증 메커니즘을 사용하는 경우 메커니즘에 적합한 설정을 지정합니다.

    security:
    transitionToAuth: true
    keyFile: <path-to-keyfile>
2

세컨더리 멤버부터 시작하여 한 번에 한 멤버씩 복제본 세트를 다시 시작합니다.

  1. 세컨더리 멤버를 한 번에 하나씩 다시 시작하려면 다음을 수행합니다.

    1. mongod 에 연결하고 admin 데이터베이스에 대해 db.shutdownServer() 메서드를 사용하여 mongod 을 안전하게 종료합니다.

      db.getSiblingDB("admin").shutdownServer()
    2. 새 구성 파일로 mongod 를 다시 시작하고 { --config 를 사용하여 구성 파일의 경로를 지정합니다. 예를 들어 새 구성 파일의 이름이 mongod-secure.conf 인 경우입니다.

      mongod --config <path>/mongod-secure.conf

      여기서 <path> 은 새 구성 파일이 포함된 폴더의 시스템 경로를 나타냅니다.

    이 멤버가 작동되면 모든 세컨더리가 업데이트될 때까지 복제본 세트의 다음 세컨더리 멤버에 대해 이 과정을 반복합니다.

  2. 모든 세컨더리 멤버가 다시 시작되고 작동되면 프라이머리 멤버를 다시 시작합니다.

    1. mongod 에 연결합니다.

    2. rs.stepDown() 메서드를 사용하여 프라이머리를 물러나고 trigger 투표를 트리거합니다.

      rs.stepDown()

      rs.status() 메서드를 사용하여 복제본 세트가 새 프라이머리를 선택했는지 확인할 수 있습니다.

    3. 프라이머리를 물러나고 새 프라이머리가 선출되면 admin 데이터베이스에 대해 db.shutdownServer() 메서드를 사용하여 이전 프라이머리를 종료합니다.

      db.getSiblingDB("admin").shutdownServer()
    4. 새 구성 파일로 mongod 를 다시 시작하고 { --config 를 사용하여 구성 파일의 경로를 지정합니다. 예를 들어 새 구성 파일의 이름이 mongod-secure.conf 인 경우입니다.

      mongod --config <path>/mongod-secure.conf

      여기서 <path> 은 새 구성 파일이 포함된 폴더의 시스템 경로를 나타냅니다.

튜토리얼의 이 시점에서 샤드 cluster의 모든 구성 요소는 --transitionToAuthsecurity.keyFile 내부 인증으로 실행 중입니다. 샤드 클러스터에는 적어도 한 명의 관리 사용자가 있으며, 각 샤드 복제본 세트에는 샤드 로컬 관리 사용자가 있습니다.

나머지 섹션에서는 샤드 클러스터를 전환 상태에서 해제하여 인증을 완전히 시행합니다.

중요

이 섹션의 마지막 부분에서 클라이언트는 샤딩된 cluster에 연결하기 위한 인증 자격 증명을 지정해야 합니다. 연결이 끊어지는 것을 방지하려면 이 섹션을 완료 하기 전에 클라이언트를 업데이트하여 인증 자격 증명을 지정하세요.

샤드 cluster에서 인증이 완전히 시행되도록 전환을 완료하려면 설정 security.transitionToAuth 없이 각 인스턴스를 다시 시작해야 합니다.mongos

1

이 튜토리얼 중에 생성된 mongos 구성 파일에서 security.transitionToAuth 키와 해당 값을 제거합니다. 튜토리얼에 추가된 security.keyFile 설정을 그대로 둡니다.

security:
keyFile: <path-to-keyfile>
2

참고

cluster에 mongos 가 하나만 있는 경우 이 단계를 수행하면 mongos 이 오프라인 상태일 때 다운타임이 발생합니다.

한 번에 하나씩 mongos 인스턴스를 다시 시작하려면 절차를 따르세요. mongos

  1. 종료하려면 mongos 에 연결합니다.

  2. admin 데이터베이스에 대해 db.shutdownServer() 메서드를 사용하여 mongos 을 안전하게 종료합니다.

    db.getSiblingDB("admin").shutdownServer()
  3. 업데이트된 구성 파일로 mongos 를 다시 시작하고 --config 를 사용하여 구성 파일의 경로를 지정합니다. 예를 들어 업데이트된 구성 파일의 이름이 mongos-secure.conf 인 경우:

    mongos --config <path>/mongos-secure.conf

이 섹션의 끝에서 모든 mongos 인스턴스는 클라이언트 인증 및 security.keyFile 내부 인증을 시행합니다.

중요

이 단계가 끝나면 클라이언트는 config 서버 복제본 세트에 연결하기 위한 인증 자격 증명을 지정해야 합니다. 연결이 끊어지는 것을 방지하려면 이 섹션을 완료 하기 전에 클라이언트를 업데이트하여 인증 자격 증명을 지정하세요.

샤드 cluster에서 인증이 완전히 시행되도록 전환을 완료하려면 설정 security.transitionToAuth 없이 각 인스턴스를 다시 시작해야 합니다.mongod

1

이 튜토리얼 중에 생성된 config 서버 구성 파일에서 security.transitionToAuth 키와 해당 값을 제거합니다. 튜토리얼에 추가된 security.keyFile 설정을 그대로 둡니다.

security:
keyFile: <path-to-keyfile>
2

세컨더리 멤버부터 시작하여 한 번에 한 멤버씩 복제본 세트를 다시 시작합니다.

  1. 세컨더리 멤버를 한 번에 하나씩 다시 시작하려면 다음을 수행합니다.

    1. mongod 에 연결하고 admin 데이터베이스에 대해 db.shutdownServer() 메서드를 사용하여 mongod 을 안전하게 종료합니다.

      db.getSiblingDB("admin").shutdownServer()
    2. 업데이트된 구성 파일로 mongod 를 다시 시작하고 { --config 를 사용하여 구성 파일의 경로를 지정합니다. 예를 들어 새 구성 파일의 이름이 mongod-secure.conf 인 경우입니다.

      mongod --config <path>/mongod-secure.conf

      여기서 <path> 은 업데이트된 구성 파일이 포함된 폴더의 시스템 경로를 나타냅니다.

    이 멤버가 활성화되면 다음 세컨더리 멤버에 대해 이 과정을 반복합니다.

  2. 모든 세컨더리 멤버가 다시 시작되고 작동되면 프라이머리 멤버를 다시 시작합니다.

    1. mongod 에 연결합니다.

    2. rs.stepDown() 메서드를 사용하여 프라이머리를 물러나고 trigger 투표를 트리거합니다.

      rs.stepDown()

      rs.status() 메서드를 사용하여 복제본 세트가 새 프라이머리를 선택했는지 확인할 수 있습니다.

    3. 프라이머리를 물러나고 새 프라이머리가 선출되면 admin 데이터베이스에 대해 db.shutdownServer() 메서드를 사용하여 이전 프라이머리를 종료합니다.

      db.getSiblingDB("admin").shutdownServer()
    4. 업데이트된 구성 파일로 mongod 를 다시 시작하고 { --config 를 사용하여 구성 파일의 경로를 지정합니다. 예를 들어 새 구성 파일의 이름이 mongod-secure.conf 인 경우입니다.

      mongod --config <path>/mongod-secure.conf

      여기서 <path> 은 업데이트된 구성 파일이 포함된 폴더의 시스템 경로를 나타냅니다.

이 섹션의 끝에서 config 서버 복제본 세트의 모든 mongod 인스턴스는 클라이언트 인증 및 security.keyFile 내부 인증을 적용합니다.

중요

이 단계가 끝나면 클라이언트는 샤드 복제본 세트에 연결하기 위한 인증 자격 증명을 지정해야 합니다. 연결이 끊어지는 것을 방지하려면 이 섹션을 완료 하기 전에 클라이언트를 업데이트하여 인증 자격 증명을 지정하세요.

샤드 cluster에서 인증이 완전히 시행되도록 전환을 완료하려면 cluster에 있는 모든 샤드 복제본 세트의 모든 구성원을 security.transitionToAuth 설정 없이 다시 시작해야 합니다.

한 번에 하나의 샤드 복제본 세트를 전환하는 경우 cluster의 각 복제본 세트에 대해 이 단계를 반복합니다.

1

이 튜토리얼 중에 생성된 config 서버 구성 파일에서 security.transitionToAuth 키와 해당 값을 제거합니다. 튜토리얼에 추가된 security.keyFile 설정을 그대로 둡니다.

security:
keyFile: <path-to-keyfile>
2

세컨더리 멤버부터 시작하여 한 번에 한 멤버씩 복제본 세트를 다시 시작합니다.

  1. 세컨더리 멤버를 한 번에 하나씩 다시 시작하려면 다음을 수행합니다.

    1. mongod 에 연결하고 admin 데이터베이스에 대해 db.shutdownServer() 메서드를 사용하여 mongod 을 안전하게 종료합니다.

      db.getSiblingDB("admin").shutdownServer()
    2. 업데이트된 구성 파일로 mongod 를 다시 시작하고 { --config 를 사용하여 구성 파일의 경로를 지정합니다. 예를 들어 새 구성 파일의 이름이 mongod-secure.conf 인 경우입니다.

      mongod --config <path>/mongod-secure.conf

      여기서 <path> 은 업데이트된 구성 파일이 포함된 폴더의 시스템 경로를 나타냅니다.

    이 멤버가 활성화되면 다음 세컨더리 멤버에 대해 이 과정을 반복합니다.

  2. 모든 세컨더리 멤버가 다시 시작되고 작동되면 프라이머리 멤버를 다시 시작합니다.

    1. mongod 에 연결합니다.

    2. rs.stepDown() 메서드를 사용하여 프라이머리를 물러나고 trigger 투표를 트리거합니다.

      rs.stepDown()

      rs.status() 메서드를 사용하여 복제본 세트가 새 프라이머리를 선택했는지 확인할 수 있습니다.

    3. 프라이머리를 물러나고 새 프라이머리가 선출되면 admin 데이터베이스에 대해 db.shutdownServer() 메서드를 사용하여 이전 프라이머리를 종료합니다.

      db.getSiblingDB("admin").shutdownServer()
    4. 업데이트된 구성 파일로 mongod 를 다시 시작하고 { --config 를 사용하여 구성 파일의 경로를 지정합니다. 예를 들어 새 구성 파일의 이름이 mongod-secure.conf 인 경우입니다.

      mongod --config <path>/mongod-secure.conf

      여기서 <path> 은 업데이트된 구성 파일이 포함된 폴더의 시스템 경로를 나타냅니다.

이 섹션의 끝에서는 샤드 cluster의 모든 mongosmongod 인스턴스가 클라이언트 인증 및 security.keyFile 내부 인증을 적용합니다. 클라이언트는 구성된 클라이언트 인증 메커니즘을 통해서만 샤드 cluster에 연결할 수 있습니다. 추가 구성 요소는 올바른 키 파일을 지정해야만 cluster에 참여할 수 있습니다.

MongoDB는 보안 TLS/SSL 연결에 사용할 수 있도록 x.509 인증서 인증을 지원합니다. 샤드 클러스터 멤버와 복제본 세트 멤버는 키파일을 사용하는 대신 x.509 인증서를 사용하여 클러스터 또는 복제본 세트에 대한 멤버십을 확인할 수 있습니다 .

자세한 내용은 x를 참조하세요. 내부 인증 을 위한 509 인증서에 대해서는 사용 x를 참조하세요.509 자체 관리형 MongoDB 를 사용한 멤버십 인증용 인증서 .

자체 관리형 MongoDB 를 키 파일 인증에서 x로 업그레이드합니다.509 인증 에서는 배포의 내부 인증 메커니즘을 키 파일 기반 인증 에서 x로 업그레이드 하는 방법을 설명합니다.509 인증서 기반 인증.

돌아가기

샤딩된 클러스터 업데이트