비밀번호 변경 (크리덴셜 회전)

개요

PlantPulse 는 내부 인프라 컴포넌트(PostgreSQL · Cassandra · Valkey · MinIO · Kafka · MQTT · Hive/Kyuubi · Temporal)에 접속하기 위한 서비스 계정을 사용합니다. 초기값은 모든 설치에서 동일하므로, 커미셔닝 시 1회 변경하는 것을 권장합니다.

중요: 비밀번호 변경은 순서를 지키지 않으면 플랫폼이 기동하지 않습니다. 보통은 아래 자동 회전(bin/passwd.sh)이 그 순서를 대신 밟습니다. 도구가 다루지 않는 값이나 워커가 있는 환경에서만 수동 절차를 씁니다. 반드시 점검 창에서 수행하고, 작업 전 백업을 확보하세요.

데이터레이크 섹션에 정리돼 있습니다

어느 키를 어떻게 바꾸는지, 실패하면 어떻게 하는지는 데이터레이크 — 비밀번호 · API 키 바꾸기 에 최신 상태로 정리돼 있습니다. 이 페이지는 그 도구가 다루지 않는 값의 수동 절차를 위해 남겨 둡니다.

자동 회전 — `passwd.sh` · `rotate-secret.sh`

설치 패키지의 bin/passwd.sh(앞문)와 bin/rotate-secret.sh(회전 엔진)가 서버측 계정 변경 · 보관소(사이드카) 갱신 · 설정 재렌더 · 순차 재시작을 한 번에 수행합니다. 수동 절차의 1~3단계를 그대로 대신합니다. 컨테이너 쪽 회전 기계는 데이터레이크 이미지의 pd secret rotate 이고, 호스트 스크립트가 그것을 부릅니다.

운영자 진입점은 호스트입니다. 컨테이너 안에서 시작하면 컨테이너가 죽을 때 진행 기록도 함께 사라져 재개할 수 없기 때문입니다.

cd /opt/kopens/plantpulse-platform-docker

# 하나만 변경
bin/rotate-secret.sh PP_PG_PASSWORD='새비밀번호'

# 여러 개 — 재시작 1회로 묶인다
bin/rotate-secret.sh PP_PG_PASSWORD='...' PP_CASSANDRA_PASSWORD='...'

# 커미셔닝 시 전체 생성
bin/rotate-secret.sh --all --generate

# 계획만 출력 — 아무것도 바꾸지 않는다
bin/rotate-secret.sh --dry-run --all --generate

인자는 반드시 변수=값 형식입니다. PP_PG_PASSWORD '새값' 처럼 공백으로 띄우면 알 수 없는 인자 로 거부됩니다.

--all 은 --generate 와 함께만 쓸 수 있습니다. --generate 는 변수마다 20자 무작위 값을 만들어 씁니다. 먼저 --dry-run 으로 대상을 확인하세요 — 어떤 변수가 걸리는지만 출력하고 사이드카도 서버측도 건드리지 않습니다.

회전 가능한 변수

레지스트리에 등록된 변수만 회전할 수 있습니다. 등록되지 않은 변수를 주면 조용히 빠뜨리지 않고 거부합니다.

환경 변수	rotator	대상 계정
`PP_PG_PASSWORD`	postgres	`plantpulse`
`PP_TEMPORAL_PASSWORD`	postgres	`temporal`
`PP_HIVE_PASSWORD`	postgres	`hive`
`PP_CASSANDRA_PASSWORD`	cassandra	—
`PP_REDIS_PASSWORD`	valkey	—
`PP_MINIO_PASSWORD`	minio	—
`PP_CEP_API_KEY`	apikey	—
`PP_DATA_GATEWAY_API_KEY`	apikey	—
`PP_DATALAKE_ADMIN_PASSWORD`	console	`admin` (관리 콘솔 로그인, 2026-09-05 추가)
`PP_DATALAKE_ADMIN_API_KEY`	apikey	— (관리 콘솔 로그 엔드포인트, 2026-09-05 추가)

--all --generate 도 이 목록만 대상으로 합니다. 2026-09-05 이전 설치 패키지에는 마지막 둘이 없습니다 — --list 가 정본입니다.

아직 등록되지 않은 변수 — PP_API_KEY, PP_FLOW_WEBHOOK_API_KEY(외부 호출자용, 검증 엔드포인트 확정 후 별건), PP_SPARK_PASSWORD · PP_TSE_PASSWORD · PP_GRAVITINO_PASSWORD · PP_KESTRA_DB_PASSWORD · PP_KESTRA_ADMIN_PASSWORD, 그리고 TLS keystore/truststore 비밀번호(인증서 교체와 얽혀 별건)입니다. 이들은 스크립트가 거부하므로 수동 절차로 변경하세요. 질의 콘솔 로그인 둘(PP_DATA_GATEWAY_WEB_PASSWORD · PP_CEP_WEB_PASSWORD)은 회전 대상이 아니라는 결정이며 사이드카 갱신 + 재시작으로 바꿉니다 → 웹 화면 로그인 계정.

PP_MQ_PASSWORD(Kafka · HiveMQ)는 아래 MQ 회전에서 별도로 다룹니다.

운영자용 앞문 — `passwd.sh`

rotate-secret.sh 를 직접 부르는 대신 쓰는 앞문입니다. 검증하고 회전 엔진을 한 번 부르는 것이 전부라 동작은 같고, 무엇을 바꿀 수 있는지 목록으로 보여 준다는 점이 다릅니다. platform · ai · studio 세 제품이 같은 이름, 같은 사용법으로 갖습니다.

cd /opt/kopens/plantpulse-platform-docker

bin/passwd.sh --list                      # 키 + 아이디 + 현재값(마스킹) + 위치
bin/passwd.sh --list --show               # 현재값 전체

bin/passwd.sh PP_MQ_PASSWORD              # 값 생략 → 프롬프트 (권장)
bin/passwd.sh PP_PG_PASSWORD=<새비번>
bin/passwd.sh PP_CASSANDRA_PASSWORD=<새비번> PP_MINIO_PASSWORD=<새비번>   # 묶으면 재시작 1회
bin/passwd.sh --dry-run PP_MQ_PASSWORD=<새비번>

별명은 없습니다 — 키는 환경 변수 이름 그대로입니다

mq, cassandra, postgres 같은 컴포넌트 이름으로는 부를 수 없습니다. 별명을 두면 이름과 변수를 잇는 매핑표를 레지스트리와 따로 맞춰야 하고, 별칭 둘이 같은 변수를 가리키는 경우("kafka 와 hivemq 는 같은 값")마다 특별 규칙이 붙습니다. 키가 곧 변수면 그 문제가 없습니다.

어느 변수가 어느 컴포넌트인지는 --list 가 알려 줍니다 — 그래서 목록이 있습니다.

바꿀 수 있는 키와, 그 값의 정본이 어디인지입니다.

키	컴포넌트	무엇으로 바뀌나
`PP_PG_PASSWORD`	PostgreSQL	명령 — `ALTER ROLE` (psql)
`PP_TEMPORAL_PASSWORD`	Temporal 의 백엔드 PostgreSQL 계정	명령 — `ALTER ROLE` (psql)
`PP_HIVE_PASSWORD`	Hive 메타스토어의 PostgreSQL 계정	명령 — `ALTER ROLE` (psql)
`PP_CASSANDRA_PASSWORD`	Cassandra	명령 — `ALTER ROLE` (cqlsh)
`PP_REDIS_PASSWORD`	Valkey	파일 — `plantpulse-storage/cache/valkey/conf/valkey.conf`
`PP_MINIO_PASSWORD`	MinIO	기동 env — `MINIO_ROOT_PASSWORD`
`PP_MQ_PASSWORD`	Kafka + HiveMQ (한 값을 공유합니다)	파일 — `kafka/config/jaas.conf` + `mqtt/conf/auth.properties`
`PP_CEP_API_KEY`	CEP API 키	파일 — `plantpulse-cep/config/plantpulse-cep.properties`
`PP_DATA_GATEWAY_API_KEY`	Data Gateway API 키	파일 — `plantpulse-data-gateway/config/plantpulse-jdbc.properties`

세 갈래의 뜻은 이렇습니다.

명령 — 서버 계정이 정본입니다. SQL/CQL 로 바꾸며, 설정 파일은 접속용 사본일 뿐입니다
파일 — 그 파일이 곧 정본입니다. 재렌더 + 재시작으로만 바뀝니다
기동 env — 프로세스 기동 시 주입됩니다. 런타임 변경 API 가 없어 재시작이 유일한 반영 수단입니다

아이디(PP_*_USER)는 바꾸지 않습니다. 보여 주기만 합니다 — 계정명 변경은 서버측 role 생성과 권한 이관까지 필요한 다른 작업입니다.

값을 생략하고 프롬프트로 입력하는 것이 권장 경로입니다 — 비밀번호가 ps 출력이나 셸 히스토리에 남지 않습니다.

레지스트리에 없는 키를 넘기면 조용히 빠뜨리지 않고 거부합니다. 오타는 비슷한 키를 제안합니다.

MQ(Kafka · HiveMQ) 회전 (설계 단계)

Kafka 와 HiveMQ 는 따로 바꿀 수 없습니다

PP_MQ_PASSWORD 하나가 두 브로커의 서버측 자격 저장소이자 클라이언트 8개의 접속 비밀번호입니다. kafka 로 부르든 hivemq 로 부르든 둘이 함께 바뀝니다.

kafka 와 hivemq 를 한 명령에 서로 다른 값으로 주면 거부합니다 — 어느 쪽이 이길지 조용히 정하지 않습니다.

Kafka 는 정적 JAAS(kafka-jaas.conf), HiveMQ 는 시큐리티 익스텐션(plantpulse-mq-auth.properties)에서 값을 읽습니다. 클라이언트 8개(plantpulse-mq · plantpulse-mqtt · plantpulse-batch · 플러그인 2종 + cluster/ 변형)도 같은 회전에서 함께 새 값을 받으므로, 클라이언트만 구 비밀번호로 남는 구멍은 없습니다.

회전 중 MQ 경로가 끊깁니다

정적 JAAS 는 신·구 비밀번호를 동시에 받아들이지 못합니다. 브로커와 소비자를 순차 재시작하는 동안 MQ 경로에 단절이 생깁니다. 무중단 회전은 지원 범위가 아닙니다 — 반드시 점검 창에서 수행하세요.

BifroMQ 는 대상이 아닙니다. 실제 MQTT 브로커는 HiveMQ 입니다.

실패했을 때 — 같은 명령을 다시 실행

롤백하지 않습니다. 되돌리려면 다시 접속해야 하는데 실패 시점에는 어느 자격증명이 유효한지 불확실해서, 되돌리는 시도가 상태를 더 망가뜨립니다. 전진 복구만 지원합니다.

실패하면 같은 명령을 그대로 다시 실행하세요. 호스트 /etc/kopens/rotation.journal(0600)에 신·구 값이 선행 기록되어 있어, 재실행하면 각 컴포넌트의 현재 상태를 판정해 이어서 수행합니다. 이미 신 자격증명으로 바뀐 컴포넌트는 건너뜁니다.

메시지	뜻	조치
`probe=NEITHER`	신·구 어느 쪽으로도 접속되지 않음	자동화가 판단할 근거가 없습니다. 사람이 상태를 확인해야 합니다
`apply 실패`	서버측 변경 실패, 즉시 중단	원인을 고치고 같은 명령 재실행
`verify 실패`	서버측은 바뀌었는데 신 값으로 접속 불가	가장 위험합니다. journal 이 `APPLIED` 로 남습니다 — 사람이 확인해야 합니다
`configure 실패`	재시작하지 않고 중단	구 설정으로 뜨면 전부 인증 실패하므로 의도된 동작입니다

워커 노드가 있으면 쓸 수 없습니다

PP_WORKER_NODES 가 설정돼 있으면 스크립트가 거부하고 중단합니다. 워커 노드마다 사이드카가 따로 있어서, 마스터만 회전하면 워커가 구 비밀번호로 남아 클러스터가 반쪽이 됩니다. 부분 성공이 가장 나쁜 실패이므로 조용히 마스터만 처리하지 않습니다.

멀티노드는 아직 지원하지 않습니다. 클러스터(멀티노드) 환경의 수동 절차를 따르세요.

왜 순서가 중요한가

비밀번호는 두 곳에 따로 존재합니다. 둘은 자동으로 동기화되지 않습니다.

①만 바꾸면 모든 클라이언트가 인증에 실패합니다.
②만 바꾸면 서버가 여전히 옛 비밀번호를 요구해 인증에 실패합니다.
③을 빠뜨리면 지금은 동작하지만 다음 컨테이너 재생성 때 옛 비밀번호가 다시 주입되어 기동에 실패합니다. 가장 놓치기 쉬운 단계입니다.

따라서 순서는 항상 ① 서버 → ③ 보관소 → ② 설정 재생성 → 재시작 입니다.

변경 가능한 계정

자동 회전 열이 «대상» 인 것은 passwd.sh 로 바꿉니다. 수동 절차는 그 밖의 값과 워커가 있는 환경을 위한 것입니다.

환경 변수	대상	서버측 변경 필요	자동 회전(예정)
`PP_PG_PASSWORD`	PostgreSQL 계정 `plantpulse`	필요	대상
`PP_TEMPORAL_PASSWORD`	PostgreSQL 계정 `temporal` (Temporal 백엔드)	필요	대상
`PP_HIVE_PASSWORD`	PostgreSQL 계정 `hive` (Hive metastore) + Hive/Kyuubi 접속 인증	필요	대상
`PP_CASSANDRA_PASSWORD`	Cassandra role	필요	대상
`PP_REDIS_PASSWORD`	Valkey `requirepass`	불필요 (설정 파일)	대상
`PP_MINIO_PASSWORD`	MinIO 루트 크리덴셜	불필요 (기동 시 주입)	대상
`PP_MQ_PASSWORD`	Kafka SASL · MQTT 브로커	불필요 (설정 파일)	대상 (MQ 회전)

PP_TEMPORAL_PASSWORD 는 Temporal 자체 계정이 아닙니다. Temporal 이 백엔드 PostgreSQL 에 접속할 때 쓰는 DB 계정입니다.

PP_HIVE_PASSWORD 는 값 하나가 양방향으로 쓰입니다. Hive metastore 가 PostgreSQL 에 접속할 때 제시하는 값이면서, 동시에 클라이언트가 HiveServer2/Kyuubi 에 접속해 올 때 검증하는 값입니다. 그래서 PostgreSQL 계정 변경과 설정 재생성을 둘 다 해야 합니다. 하나만 하면 metastore 또는 HiveServer2 중 한쪽이 죽습니다.

수동 절차

다음 경우에 이 절차를 씁니다 — 자동 회전이 다루지 않는 변수(TLS keystore/truststore, Spark · TSE · Gravitino · Kestra 계정 등), 그리고 워커 노드가 있어 스크립트가 거부하는 환경입니다. 그 밖에는 bin/passwd.sh 가 이 절차를 대신합니다.

1단계 — 서버측 계정 변경

구 비밀번호로 접속해서 변경합니다. 이 단계를 건너뛰면 나머지가 모두 무의미합니다.

PostgreSQL (계정 3개 — 바꾸려는 것만):

psql -U plantpulse -c "ALTER USER plantpulse PASSWORD '새비밀번호';"
psql -U temporal   -d temporal -c "ALTER USER temporal PASSWORD '새비밀번호';"
psql -U hive       -d hive     -c "ALTER USER hive     PASSWORD '새비밀번호';"

Cassandra:

cqlsh -u cassandra -p 구비밀번호 \
  -e "ALTER ROLE cassandra WITH PASSWORD = '새비밀번호';"

Cassandra 는 변경 직후 약 2초간 신·구 어느 쪽으로도 접속되지 않습니다. cassandra.yaml 의 credentials_validity(기본 2000ms) 자격증명 캐시 때문입니다. 변경 직후 접속 실패를 보더라도 실패로 판단하지 말고 3~5초 후 다시 확인하세요.

Valkey · MinIO · Kafka · MQTT 는 서버측에 저장된 계정이 없습니다 — 설정 파일과 기동 환경변수가 정본이므로 이 단계가 필요 없습니다.

⚠ 변경 직후 반드시 새 비밀번호로 접속해 보세요

ALTER USER 는 잘못된 값을 넣어도 성공(ALTER ROLE)을 반환합니다. 성공 메시지는 "명령이 실행됐다"는 뜻일 뿐 "의도한 값이 들어갔다"는 보장이 아닙니다.

가장 흔한 사고는 따옴표 처리 실수입니다. 셸 변수를 작은따옴표 안에 넣으면 확장되지 않고 문자 그대로 저장됩니다.

# ✗ 위험 — 변수가 확장되지 않아 '$NEW_PW' 라는 문자열이 비밀번호가 된다.
#          그런데도 ALTER ROLE 은 성공을 반환한다.
psql -U hive -c 'ALTER USER hive PASSWORD "$NEW_PW";'

# ✓ 안전 — 값을 직접 적거나, 확장되는 문맥인지 확인한다
psql -U hive -c "ALTER USER hive PASSWORD '실제새비밀번호';"

그래서 각 계정을 바꾼 직후 그 자리에서 접속을 확인하세요. 다음 단계로 넘어간 뒤에 발견하면 원인을 찾기 어렵습니다.

PGPASSWORD='새비밀번호' psql -U hive -h 127.0.0.1 -d postgres -w -tAc "SELECT 1"
# 1 이 나오면 정상. 인증 실패면 값이 의도와 다르게 들어간 것이다.

접속이 안 되면 구 비밀번호가 아직 유효한지 먼저 확인하세요. 유효하다면 변경이 반영되지 않은 것이고, 구·신 둘 다 안 되면 의도치 않은 값이 들어간 것이므로 그 값을 찾아 다시 접속해 바로잡아야 합니다.

비밀번호에 작은따옴표(')가 들어가면 SQL/CQL 문 안에서 두 개로 이스케이프해야 합니다 (a'b → 'a''b').

2단계 — 보관소(사이드카) 갱신

이 단계를 빠뜨리면 다음 재시작에서 옛 비밀번호가 다시 주입됩니다.

설정 정본은 /etc/kopens/plantpulse-platform.env 하나입니다

플랫폼의 비밀은 repo 트리 밖인 /etc/kopens/ 에 0600 으로 있습니다. 정본은 한 파일뿐입니다.

ls -l /etc/kopens/

파일	상태
`/etc/kopens/plantpulse-platform.env`	정본 — platform · ai · studio 세 제품 공통 규약(`plantpulse-<제품>.env`)
`/opt/kopens/plantpulse-platform.env`	2026-08-25 ~ 08-29 에만 쓰이던 경로. 읽지도 쓰지도 않습니다 — 남아 있으면 설치 스크립트가 정본으로 되돌립니다

platform.env.generated 는 더 이상 존재하지 않습니다(2026-08-22 삭제). 같은 이유로 platform-credentials.txt 도 폐기됐습니다(2026-08-16) — 같은 비밀을 두 벌로 들고 있었는데 회전 엔진이 그 파일을 갱신하지 않아, 비밀번호를 바꾼 뒤에도 옛 값을 안내했습니다. 값을 볼 때도 사이드카 하나만 봅니다.

sudo vi /etc/kopens/plantpulse-platform.env

해당 export PP_..._PASSWORD=... 줄을 새 값으로 수정합니다. 파일 권한은 0600 을 유지하세요.

sudo chmod 600 /etc/kopens/plantpulse-platform.env

3단계 — 재시작

호스트에서 스택을 재시작합니다. 설정 재생성은 기동 과정에 포함되어 있습니다.

cd /opt/kopens/plantpulse-platform-docker/bin
./restart.sh       # graceful drain → 재기동 → 준비될 때까지 대기 (0 = 쓸 수 있다)

데이터레이크 컨테이너는 기동할 때 템플릿을 다시 렌더링합니다. 따라서 컴포넌트 설정 파일을 직접 수정하면 재시작 때 템플릿 값으로 되돌아갑니다. 설정은 호스트의 /etc/kopens/conf (컨테이너의 plantpulse-datalake-cli/config/templates 로 바인드 마운트) 에서 바꾸세요.

앱 여섯은 템플릿을 렌더링하지 않습니다 — compose 가 넘긴 환경변수로만 값을 받습니다.

4단계 — 검증

# 플랫폼 전체 상태 (호스트에서) — 0 = 정상 / 2 = 비정상
cd /opt/kopens/plantpulse-platform-docker/bin
./status.sh
./ops-check.sh

# 각 컴포넌트가 새 비밀번호로 실제 접속되는지 (데이터레이크 컨테이너 안에서)
./shell.sh
/opt/kopens/plantpulse-platform/plantpulse-datalake-cli/bin/pd node psql -c "SELECT 1;"
/opt/kopens/plantpulse-platform/plantpulse-datalake-cli/bin/pd node cql -e "SELECT now() FROM system.local;"
exit

헬스 API 가 OK 또는 WARN 을 반환하면 정상입니다.

curl -kfsS https://<서버IP>:4950/api/health | jq .status

클러스터(멀티노드) 환경

워커 노드가 있는 환경에서는 마스터만 변경하면 안 됩니다.

워커 노드도 자체 /etc/kopens/plantpulse-platform.env 를 가지고 컨테이너에 주입합니다. 마스터에서만 변경하면 워커가 옛 비밀번호로 남아 클러스터가 반쪽만 동작합니다.

모든 워커 노드에서 2단계(사이드카 갱신)와 3단계(재시작) 를 동일하게 수행하세요. 1단계(서버측 변경)는 공유 자원이므로 한 번만 하면 됩니다.

실패했을 때

증상	원인	조치
변경 직후 모든 컴포넌트 인증 실패	1단계만 하고 3단계 미수행	호스트에서 `bin/restart.sh`
재시작 후 옛 비밀번호로 되돌아감	2단계(사이드카) 누락	`/etc/kopens/plantpulse-platform.env` 수정 후 재시작. 사이드카가 `bin/env.sh` 도 셸 export 도 이깁니다
Cassandra 만 접속 실패	자격증명 캐시(2초)	3~5초 후 재확인
Hive/Kyuubi 는 되는데 metastore 오류	PostgreSQL `hive` 계정 미변경	1단계의 `ALTER USER hive` 수행
`ALTER ROLE` 은 성공했는데 접속 실패	따옴표 실수로 의도와 다른 값이 저장됨	1단계의 검증 절차 참조 — 성공 반환은 값의 정확성을 보장하지 않는다
특정 경로만 실패	일부 설정 파일 미갱신	데이터레이크 컨테이너 안에서 `./configure.sh` 재실행 후 아래 명령으로 잔존 확인

배포된 설정에 치환되지 않은 자리표시자가 남아 있는지 확인:

# 데이터레이크 컨테이너 안에서
grep -rn '\${PP_' /opt/kopens/plantpulse-platform/ \
  --include='*.conf' --include='*.properties' --include='*.xml' --include='*.yaml' \
  | grep -v '/plantpulse-datalake-cli/config/templates/'
# 아무것도 나오지 않아야 정상입니다

중간에 실패해 한쪽만 바뀐 상태라면, 어느 비밀번호가 유효한지부터 확인하세요.

PGPASSWORD='구비밀번호' psql -U plantpulse -h 127.0.0.1 -c "SELECT 1;"   # 구 값으로 접속되는가
PGPASSWORD='새비밀번호' psql -U plantpulse -h 127.0.0.1 -c "SELECT 1;"   # 신 값으로 접속되는가

구 값으로 접속됨 → 1단계가 적용되지 않았습니다. 1단계부터 다시 수행하세요.
신 값으로 접속됨 → 1단계는 끝났습니다. 2·3단계만 수행하면 됩니다.

컨트롤 센터(ppctl) 운영자 계정

현행 컨테이너 출하본에서는 이 화면에 접근할 수 없습니다

compose 스택의 어떤 컨테이너도 9700 포트를 호스트에 publish 하지 않습니다. systemctl restart ppctl 도 컨테이너 안에서 도는 스택에는 해당하지 않습니다.

아래 내용은 컨트롤 센터를 별도로 운용하는 환경을 위해 남겨 둔 것입니다. 컨테이너 환경에서 플랫폼을 기동·정지·제어하는 방법은 시스템 시작 및 종료의 공통 동사(up.sh · down.sh · restart.sh · status.sh)입니다.

앞의 절차와 완전히 별개인 비밀번호가 하나 더 있습니다. 컨트롤 센터(ppctl)는 포트 9700 에서 도는 별도 웹 화면이고, 자기만의 로그인 계정을 씁니다. 이 계정은 플랫폼 웹 콘솔 계정도, 위의 인프라 서비스 계정도 아닙니다.

기본값 그대로 두지 마세요

컨트롤 센터는 플랫폼 전체를 root 권한으로 기동·정지·제어하는 화면입니다. 환경 변수를 설정하지 않으면 모든 설치에서 동일한 개발용 기본 계정(사용자명 admin)으로 로그인됩니다. 커미셔닝 때 반드시 바꾸세요.

변경 방법

환경 변수 두 개로 정합니다. 값을 주면 기본값 대신 그 값이 쓰입니다.

환경 변수	용도
`PP_CONTROL_USER`	컨트롤 센터 로그인 사용자명
`PP_CONTROL_PASSWORD`	컨트롤 센터 로그인 비밀번호

컨트롤 센터를 띄우는 환경(plantpulse-startup 의 환경 파일 또는 systemd 유닛 ppctl.service 의 Environment=)에 위 두 값을 설정합니다.
컨트롤 센터를 재시작합니다.
```
systemctl restart ppctl
```
https://[HOST]:9700 에 새 값으로 로그인되는지 확인합니다.

이 계정은 화면에서 바꾸는 기능이 없습니다. 환경 변수를 고치고 재시작하는 것이 유일한 변경 방법입니다.

`PP_CONTROL_NOAUTH` 는 운영에서 켜지 마세요

PP_CONTROL_NOAUTH=1(또는 JVM 옵션 -Dppctl.noauth=1) 을 주면 컨트롤 센터의 로그인이 통째로 비활성화됩니다. 신뢰망 데모용 스위치이고 기본값은 꺼짐입니다.

포트 9700 에 닿을 수 있는 누구나 인증 없이 플랫폼 전체를 제어할 수 있게 되므로, 운영 환경에서는 켜지 말고 방화벽에서 9700 접근도 운영자 대역으로 제한하세요.

주의 사항

비밀번호에 작은따옴표(')를 쓸 경우 SQL/CQL 문 안에서는 두 개로 이스케이프해야 합니다 (a'b → 'a''b').
변경 이력과 새 비밀번호는 안전한 곳에 보관하세요. /etc/kopens/platform-credentials.txt 에 현재 값이 기록되지만, 이 파일은 평문이므로 권한(0600)을 반드시 유지해야 합니다.
CEP · Data Gateway 의 API 키(PP_CEP_API_KEY · PP_DATA_GATEWAY_API_KEY)는 서버와 소비자가 같은 값을 각자 읽어 비교하는 방식입니다. 한쪽만 바꾸면 즉시 401 이 발생하므로 양쪽을 함께 변경해야 합니다. 두 키 모두 자동 회전 대상입니다.
자동 회전이 남기는 /etc/kopens/rotation.journal 에는 신·구 값이 인코딩되어 기록됩니다. 사이드카와 같은 민감도이므로 권한 0600 을 유지하세요.

개요​

자동 회전 — passwd.sh · rotate-secret.sh​

회전 가능한 변수​

운영자용 앞문 — passwd.sh​

MQ(Kafka · HiveMQ) 회전 (설계 단계)​

실패했을 때 — 같은 명령을 다시 실행​

왜 순서가 중요한가​

변경 가능한 계정​

수동 절차​

1단계 — 서버측 계정 변경​

⚠ 변경 직후 반드시 새 비밀번호로 접속해 보세요​

2단계 — 보관소(사이드카) 갱신​

3단계 — 재시작​

4단계 — 검증​

클러스터(멀티노드) 환경​

실패했을 때​

컨트롤 센터(ppctl) 운영자 계정​

변경 방법​

PP_CONTROL_NOAUTH 는 운영에서 켜지 마세요​

주의 사항​

관련 문서​

개요