1. 개념부터 정리
MongoDB는 크게 두 상태 중 하나입니다.
- authorization 꺼짐 (–-auth 없음, security.authorization: disabled)
- 비번 여부 상관 없이 모든 연결이 풀 권한
- 클라이언트가 username/password를 보내도 그냥 무시하고 동작
- authorization 켜짐 (–-auth, security.authorization: enabled)
- 모든 요청은 인증 필수
- 유저/롤 기반 권한 체크 수행
즉, “비번 있어도 되고 없어도 되고” 라는 중간 모드는 없어요.
하지만 auth 끄고 있는 동안에도 미리 계정을 만들어 놓고,
앱 쪽은 비번을 먼저 사용하게 바꾸는 건 가능합니다.
2. 전체 전략 요약 (거의 무중단 버전)
- 현재: auth OFF 상태
- 관리용/앱용 사용자 미리 생성 (auth OFF 상태에서)
- Spring Boot 설정을 수정해서 username/password로 접속하도록 배포
- 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)라고 가정.
- secondary 1
- mongod stop
- conf 수정 (authorization: enabled, keyFile 설정)
- mongod start
- rs.status()로 정상 동기 확인
- secondary 2
- 위와 동일하게
- primary
- primary를 마지막에 재시작 → 이때 잠깐 primary 선거가 일어날 수 있지만
Driver가 잘 잡아주면 애플리케이션은 거의 문제없이 넘어감
- primary를 마지막에 재시작 → 이때 잠깐 primary 선거가 일어날 수 있지만
이 과정을 통해 전체 replica set이 auth ON 상태로 전환됩니다.
4. 진짜 “무중단”이 가능한가?
- 싱글 인스턴스 MongoDB라면:
- auth 켜려면 어쨌든 한 번은 mongod 재시작이 필요 → 짧은 다운은 피하기 어려움
- 3대 replica set이라면:
- 각 노드를 하나씩 재시작하는 롤링 방식으로
사용자 입장에서는 거의 무중단에 가깝게 전환 가능 - 순간적인 primary 선거 동안 짧은 hiccup 정도는 있을 수 있음
- spring-data-mongodb와 드라이버가 replica set + 재시도를 잘 처리해주면 체감 거의 없음
- 각 노드를 하나씩 재시작하는 롤링 방식으로
5. 질문하신 포인트에 대한 답 정리
비번이 없어도 동작하고 비번이 있어도 동작하도록 했다가,
나중에 비번 없이는 안 돌게 바꾸는 게 되나요?
- Yes, 이 순서로 가능합니다:
- auth OFF 상태에서 사용자 계정들 미리 생성
- Spring Boot를 먼저 username/password 쓰게 배포
→ 이때는 “비번 있어도/없어도” 모두 동작하는 상태 (auth OFF니까) - MongoDB에 authorization: enabled 설정 후 롤링 재시작
→ 이제는 비번 없이는 안 되는 상태로 전환



