search

hongkunyoo / blog-comments

blog comments for utteranc.es
1 stars 0 forks source link

k8s 인증 완벽이해 #1 - X.509 Client Certs | 커피고래의 노트 #32

Open utterances-bot opened 2 years ago

utterances-bot commented 2 years ago

k8s 인증 완벽이해 #1 - X.509 Client Certs | 커피고래의 노트

쿠버네티스를 지금까지 사용해 오면서 어렴풋이만 인증서와 토큰을 이용하여 사용자 인증을 하는지는 알고 있엇지만 그 이상 다른 방법에 대해서는 자세히 몰랐었습니다. 쿠버네티스 공인 자격증(CKA)을 취득하기 위해 잠깐 인증서를 이용한 사용자 인증

https://coffeewhale.com/kubernetes/authentication/x509/2020/05/02/auth01/

eunbin079 commented 2 years ago

완벽 깔끔 입네다

kingbj940429 commented 2 years ago

정말 최고의 글입니다 감사합니다 !!

hongkunyoo commented 2 years ago

@kingbj940429 님, 감사합니다~ㅎㅎ

happycloudpak commented 2 years ago

쿠버네티스 공식 문서 보고 뭔소린가 했는데 커피고래님의 글은 정말 쉽게 이해되네요. 좋은 글 감사합니다.

KangJungHwa commented 2 years ago

정말 좋은 자료 공유 감사합니다.

ShinJam commented 2 years ago

안녕하세요 좋은글 감사합니다. 궁금한게 있어서 댓글 남깁니다.

curl --cacert rootCA.pem --cert client.pem --key client-key.pem  https://localhost:8443/

private key가 사용되면 노출 위험이 있는 것 아닌가요?

hongkunyoo commented 2 years ago

@ShinJam 님, 안녕하세요. 제 글에 관심 가져 주셔서 감사합니다.

private key가 사용되면 노출 위험이 있는 것 아닌가요?

네, 말씀하신대로 private key이기 때문에 노출되면 보안의 위험이 있는 게 맞습니다. 쿠버네티스를 kubeadm으로 생성하신 다음, 처음 받아오는 /etc/kubernetes/admin.conf도 이러한 방법을 이용하여 쿠버네티스로 접근하고 있습니다. 그렇기 때문에 OIDC 로그인 등으로 조금 더 secured한 방법으로 쿠버네티스를 사용하는 것이 권장됩니다.

private key가 노출이 되는 것은 Service Account의 token (Bearer Token), OIDC의 사용자 패스워드가 노출되는 것과 동일하게 위험합니다. 다만 Service Account와 OIDC 패스워드는 Token 삭제 및 비밀번호 변경으로 노출되더라도 막을 방법이 있습니다만 Certificate 및 private key는 root CA가 signing한 것이기 때문에 root CA를 교체하지 않는 이상 노출된 것을 막을 방법이 없기에 더 신중해야 할 것 같습니다. (참고: https://stackoverflow.com/a/56540482)

그래서 결론적으로 말씀하신 것처럼 노출의 위험이 있고 그 영향이 크기 때문에 production cluster에서 권장되지는 않을 것 같습니다.

devhak2 commented 2 years ago

안녕하세요. 먼저 좋은글에 대해서 감사의 말씀 올립니다. 최근에 쿠버네티스 관련하여 커피고래님 블로그에서 많은 깨달음을 얻고 있는데요. 다만 해당 포스팅 중 제가 알고 있는 것과는 다른 내용이 있어서 댓글 드립니다. 클라이언트 인증서의 소유권을 주장하기 위해서 key를 전달해야 된다고 본문에 적어 놓으셨는데 인증서 소유권을 주장하기 위해서 private key를 가지고 있다는 사실만 전달하면 되지 않을까요? 특정 데이터를 private key로 signing해서 전달하면 공개키로 풀어볼 수 있으니 충분히 가능하지 않을까 싶습니다. 실제로도 https://wiki.openssl.org/index.php/SSL_and_TLS_Protocols#Client_Authentication 여기에 나와있는 것처럼 SSL handshake 과정에서 주고 받은 메시지들의 digest를 클라이언트의 private key로 signing 한다고 나와 있는데요. 제가 알기로도 curl의 --key 옵션은 key를 전달하는 것이 아닌 signing에 쓰일 private key를 지정하는 것으로 알고 있습니다. 혹시 제 지식이 잘못된걸 수도 있어서 한번 코멘트 남겨봅니다.

hongkunyoo commented 2 years ago

@devhak2님, 확인 감사합니다. 해당 내용에 대해서 본문 내용 수정하였습니다. 감사합니다!

kgw7401 commented 1 year ago

항상 좋은 글 감사합니다

prudentcircle commented 2 weeks ago

좋은 글 써주셔서 감사합니다!