Add encryption decryption script for credentials

[seokho-son]

to enhance security.

Force encrypting credentials.yaml into credentials.yaml.enc

To protect sensitive information, credentials.yaml is not used directly. Instead, it must be encrypted using encCredential.sh. The encrypted file credentials.yaml.enc is then used by init.py. This approach ensures that sensitive credentials are not stored in plain text.

If you need to update your credentials, decrypt the encrypted file using decCredential.sh, make the necessary changes to credentials.yaml, and then re-encrypt it.

• Encrypting Credentials

  scripts/init/encCredential.sh

• Decrypting Credentials

  scripts/init/decCredential.sh

[seokho-son]

암호화

[seokho-son]

복호화

[seokho-son]

암호화되지 않은 credentials.yaml 파일은 허용하지 않도록 처리함. (암호화 필수)

[seokho-son]

암호화된 파일이 있고, 정확한 암호키가 입력된 경우에만, init 작업(credential 등록 등) 진행.

[seokho-son]

@yunkon-kim Ready for a review. :)

[yunkon-kim]

@seokho-son

Tumblebug을 조금 더 안전하게 활용할 수 있는 기능이 추가되었네요 ^^

아래와 같이 동작하는 것으로 이해했습니다.

• 운영자/개발자가 Password를 입력하면, 해당 Password로 credential 암/복호화
• Password를 입력하지 않으면, base64 random bytes인 Passkey를 생성 및 이를 활용한 credential 암/복호화

개인적으로 KEY_FILE="$CRED_PATH/cred_key"가 취약한 포인트가 될 수 있다고 보여 의견을 말씀드립니다.

운영자/개발자가 위험성에 대해 충분히 인지해야 할 필요가 있고, Password/Passkey를 알려진 개발 문화(예, .env)를 바탕으로 직접, 안전하게 관리해야 한다는 취지의 의견입니다.

1. encCredential.sh, decCredential.sh 상에서 KEY_FILE 관련 부분을 없애고, decCredential.sh 실행시, 운영자/개발자가 직접 Password/Passkey를 입력하도록 개선
2. TB에서 KEY_FILE 대신, 잘 알려진(?) .env 읽는 것으로 대체하고, 마찬가지로 운영자/개발자가 직접 Password/Passkey를 .env에 입력해야만 하도록 개선

더하여, 출력 메시지 및 주석에 경고 문구가 추가되면 좋을 것 같습니다.

[seokho-son]

@yunkon-kim 리뷰 및 의견 감사합니다! KEY_FILE="$CRED_PATH/cred_key"가 취약한 포인트가 될 수 있다는 의견에 공감합니다.

저도 고민이 많았어서, 이리저리 여러 방법으로 변경해서 사용해보고 올린 최종안이었습니다.
일단 현재 KEY_FILE="$CRED_PATH/cred_key" 의 취지는 1회 확인 용도로 사용자가 알아서 관리하게 하기 위함이었습니다.
시스템이 생성한 키를 사용자에게 1회라도 알려 주기는 해야 해서, 결국 파일로 저장하였습니다.

사용자에게 알려주는 방법은 3가지 정도가 있을 것 같은데 각각 장단점이 있었습니다.

1. stdout으로 1회 출력

• 장점: 간편하며, 관리를 사용자에게 일임 가능
• 단점: 키가 화면상에 노출(특히 사용자가 직접 입력한 비밀번호는 노출되면 안됨. 다른 곳에서 활용하고 있는 개인 패턴일 수 있음), 자동 생성된 키의 경우 문자열 길이가 길어서 암기하거나 비밀번호처럼 사용하기가 어려움.

2. 환경변수(TB_CRED_DECRYPT_KEY 등)에 넣어주고, 조회가 필요한 환경변수명을 stdout으로 출력하여 가이드

• 장점: 화면에 바로 노출되지는 않음. 비교적 간결
• 단점: 해당 환경변수를 조회해보지 않으면 안되는 상황(다른 컴퓨터에서도 활용하는 것을 가정)이 있으며, 이 경우 사용자가 환경변수를 조회함으로써 다시 stdout으로 노출될 수 있음. 조회하지 않고 내부 처리하게 하려고 하는 경우, 스크립트를 source로 실행시켜야 하는 불편함이 있음.

3. 임시 파일에 기록, 사용자는 파일 단위로 조회 및 활용

• 장점: 사용자에게 관리를 맡기기 수월함 (임시 파일이므로, 확인하고 알아서 잘 관리하라고 가이드). 환경변수의 휘발성 고민 필요 없음 등
• 단점: 사용자가 가이드를 따르지 않고, 임시 파일을 영구적으로 활용하게 될 보안 취약 가능성이 있음

4. a Secret manager를 도입해서, Secret으로 저장하고, 사용자는 Secret manager를 통해 조회 및 활용

• 단점: Secret manager 도입을 사용자에게 강제해야 함. 단순한 Secret manager도 생각보다는 설치, 활용 등에서 복잡성 유발됨.

말씀해주신 제안을 중심적으로 보자면,

운영자/개발자가 위험성에 대해 충분히 인지해야 할 필요가 있고, Password/Passkey를 알려진 개발 문화(예, .env)를 바탕으로 직접, 안전하게 관리해야 한다는 취지의 의견입니다.

• 알려진 개발 문화(예, .env): 를 적용하는 것이 바람직할지는 의문이 있습니다.
  • 현재 제안된 스크립트는 init.py 라고하는 초기화용 도구에만 적용되어 있는 사항이다보니, 본래 시스템(CB-TB 서버)에 해당하는 사항은 아니고, 지원도구에 대한 사항 정도로 보는 것이 좋을 것 같습니다.
  • .env 파일 자체는 오히려 사용자의 비번을 시스템적으로 활용하는 것을 가이드하는 형상이 될 수 있을 것 같습니다. 결국 .env에 비번을 저장하게 되는 형상인 것이죠. 이렇게 되면, 기존에 credentials.yaml을 그대로 파일로 노출시키는 것과 크게 다르지 않을 수도 있다는 생각이 들었습니다. (참고: 현재 cred_key는 임시 활용을 가정하고 있습니다.)

1. encCredential.sh, decCredential.sh 상에서 KEY_FILE 관련 부분을 없애고, decCredential.sh 실행시, 운영자/개발자가 직접 Password/Passkey를 입력하도록 개선

• SSH에서 PEM 키를 발급하거나, 암호로 처리하게 하거나~ 둘 다 지원하는 것과 마찬가지 형상인 것으로 이해해주시면 될 것 같습니다.
• KEY_FILE 활용 여부는 상기 이슈에서 함께 살펴보면 될 것 같고요.

2. TB에서 KEY_FILE 대신, 잘 알려진(?) .env 읽는 것으로 대체하고, 마찬가지로 운영자/개발자가 직접 Password/Passkey를 .env에 입력해야만 하도록 개선

• 위에서 말씀드렸지만, .env 활용은 다소 관점 차이가 있을 것 같습니다.

:)

논의를 위한 생각 공유 자료라고 생각해주심 되겠습니다! :)

[yunkon-kim]

@seokho-son 여러가지로 고민이 많으셨을 것 같습니다.

공유 차원의 의견을 말씀드립니다.

스크립트를 구동하면서 사용자가 입력한 Password가 노출되면 안된다는 것은 전적으로 동일하게 생각합니다.

Passkey를 자동 생성하여 임시 파일에 저장할 시, 경고 문구에도 불구하고 삭제되지 않을 가능성이 있다는 것에서 출발한 의견이었습니다. 그래서, Passkey이를 사용자가 직접 관리해야 한다는 취지였고, 어떤 특정한 파일에 Passkey를 저장해 두는 것도 사용자가 직접해야만 하는 것으로 보았습니다.

관련하여 조금만 더 자세히 말씀드려보겠습니다.

• Passkey는 stdout으로 출력되어도 괜찮다고 생각합니다.
• 사용자는 출력된 Passkey를 각자의 방식으로 안전하게 관리해야 할 것입니다.
  • 예를 들어, 암호화, 압축, 노트 앱, 메모장, 등 각자가 안전하다고 판단하는 곳에서 관리할 수 있습니다.
• decCredential.sh 또는 init.py 을 실행하고, Prompt에 Passkey를 복사 및 붙여넣기 하는 방식이 좋을 것 같습니다.

단, 개발과 관련한 편의를 위해, 개발 환경에서만 제한적/한시적으로 cred_key 또는 .env에 Passkey를 저장 및 활용할 수 있겠습니다.

• 이 경우, 사용자가 직접 파일을 생성 및 Passkey를 저장해야할 필요가 있고, 활용이 끝난 후에는 직접 삭제하는 것이 필수일 것 입니다.

[seokho-son]

임시 암호키 파일을 저장할지, Stdout으로 출력할지, 사용자에게 물어봐서 처리하게 함. (다양한 경고 메시지 추가)

---

임시 키 파일을 저장하는 경우

(암호화)

(복호화)

---

키를 화면에 출력하는 경우

(암호화)

(복호화)

[seokho-son]

@yunkon-kim 리뷰 의견을 반영하여 개선해보았습니다. :)

[seokho-son]

추가 커밋을 통해서, cred_key 임시 파일의 파일명을, .tmp_enc_key 로 변경하였습니다. (임시 파일이라는 것을 표현, . 로 자동 숨김 활용 등)

[yunkon-kim]

LGGGGGTM :->