1. 개념부터 정리

MongoDB는 크게 두 상태 중 하나입니다.

  1. authorization 꺼짐 (–-auth 없음, security.authorization: disabled)
    • 비번 여부 상관 없이 모든 연결이 풀 권한
    • 클라이언트가 username/password를 보내도 그냥 무시하고 동작
  2. authorization 켜짐 (–-auth, security.authorization: enabled)
    • 모든 요청은 인증 필수
    • 유저/롤 기반 권한 체크 수행

즉, “비번 있어도 되고 없어도 되고” 라는 중간 모드는 없어요.
하지만 auth 끄고 있는 동안에도 미리 계정을 만들어 놓고,
앱 쪽은 비번을 먼저 사용하게 바꾸는 건 가능
합니다.


2. 전체 전략 요약 (거의 무중단 버전)

  1. 현재: auth OFF 상태
  2. 관리용/앱용 사용자 미리 생성 (auth OFF 상태에서)
  3. Spring Boot 설정을 수정해서 username/password로 접속하도록 배포
  4. MongoDB 설정에 auth 켜고, replica set이면 노드별 롤링 재시작

이 순서로 하면:

  • 앱 입장:
    • 1~3단계: 비번 없어도 잘 되고, 비번 보내도 잘 됨 (auth OFF라 그냥 통과)
    • 4단계: auth ON 이후에도 이미 비번을 보내고 있으므로 정상 동작
  • 기존 “비번 안 쓰는 옛날 설정” 앱은
    • 4단계 이후부터는 접속 실패 → 이 때 이미 전부 새 설정으로 바꿔 둔 상태여야 함

3. 단계별로 조금 더 구체적으로

✅ 1단계: 관리자/앱 계정 만들기 (auth OFF 상태에서)

mongosh(또는 mongo)로 접속:

 
mongosh --host <primary-host>:27017

admin DB에서 계정 생성:

 
use admin; // 관리용 계정 (DBA용) db.createUser({ user: "adminUser", pwd: "강력한_비번", roles: [ { role: "userAdminAnyDatabase", db: "admin" }, { role: "dbAdminAnyDatabase", db: "admin" }, { role: "readWriteAnyDatabase", db: "admin" }, ] }); // 애플리케이션용 계정 (권한 최소화) db.createUser({ user: "appUser", pwd: "또_다른_강력한_비번", roles: [ { role: "readWrite", db: "yourAppDb" } // 실제 사용하는 DB명 ] });

주의: 지금은 auth OFF라 사실상 아무 제약 없이 createUser가 되지만,
나중에 auth ON 하면 이 계정들이 진짜로 쓰이게 됩니다.


✅ 2단계: Spring Boot 쪽에서 먼저 비번 사용하도록 변경

application.yml 예시 (mongoTemplate 쓰는 경우도 똑같이 설정):

 
spring: data: mongodb: uri: mongodb://appUser:또_다른_강력한_비번@host1:27017,host2:27017,host3:27017/yourAppDb?replicaSet=rs0&authSource=admin

혹은 application.properties:

 
spring.data.mongodb.uri=mongodb://appUser:또_다른_강력한_비번@host1:27017,host2:27017,host3:27017/yourAppDb?replicaSet=rs0&authSource=admin

그리고 이 설정으로 애플리케이션 배포/롤링 배포를 먼저 합니다.

  • 이 시점에는 Mongo가 auth OFF →
    비번이 틀려도 연결은 그냥 성공합니다.
  • 하지만 나중에 auth ON 하면 이 계정 정보가 실제로 사용되죠.

✅ 3단계: MongoDB에 auth 활성화 (security.authorization: enabled)

3-1. mongod.conf 수정

각 노드의 /etc/mongod.conf (또는 사용 중인 conf)에서:

 
security: authorization: enabled # replica set이면 keyFile도 같이 설정해야 함 (이미 쓰고 있을 수도 있음) # keyFile: /etc/mongo-keyfile

replica set인데 아직 keyFile 안 쓰고 있다면,
별도로 keyfile 생성해서 세 노드에 같은 파일/권한으로 배포해야 합니다.
(이건 내부 노드 간 인증용)

3-2. replica set이라면 롤링 재시작

예: 노드 3대 (primary 1 + secondary 2)라고 가정.

  1. secondary 1
    • mongod stop
    • conf 수정 (authorization: enabled, keyFile 설정)
    • mongod start
    • rs.status()로 정상 동기 확인
  2. secondary 2
    • 위와 동일하게
  3. primary
    • primary를 마지막에 재시작 → 이때 잠깐 primary 선거가 일어날 수 있지만
      Driver가 잘 잡아주면 애플리케이션은 거의 문제없이 넘어감

이 과정을 통해 전체 replica set이 auth ON 상태로 전환됩니다.


4. 진짜 “무중단”이 가능한가?

  • 싱글 인스턴스 MongoDB라면:
    • auth 켜려면 어쨌든 한 번은 mongod 재시작이 필요 → 짧은 다운은 피하기 어려움
  • 3대 replica set이라면:
    • 각 노드를 하나씩 재시작하는 롤링 방식으로
      사용자 입장에서는 거의 무중단에 가깝게 전환 가능
    • 순간적인 primary 선거 동안 짧은 hiccup 정도는 있을 수 있음
    • spring-data-mongodb와 드라이버가 replica set + 재시도를 잘 처리해주면 체감 거의 없음

5. 질문하신 포인트에 대한 답 정리

비번이 없어도 동작하고 비번이 있어도 동작하도록 했다가,
나중에 비번 없이는 안 돌게 바꾸는 게 되나요?

  • Yes, 이 순서로 가능합니다:
    1. auth OFF 상태에서 사용자 계정들 미리 생성
    2. Spring Boot를 먼저 username/password 쓰게 배포
      → 이때는 “비번 있어도/없어도” 모두 동작하는 상태 (auth OFF니까)
    3. MongoDB에 authorization: enabled 설정 후 롤링 재시작
      → 이제는 비번 없이는 안 되는 상태로 전환
Posted by yongary
,