POD내부에서 외부로 나가는 통신 시 self signed certificate 이슈가 발생한다면? (인증서 설정이 없음에도)

2023. 1. 24. 21:56

클러스터 안에 있는 jenkins pod에서 플러그인을 설치할려 했더니 다음과 같은 에러가 발생하였습니다

sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at java.base/sun.security.provider.certpath.SunCertPathBuilder.build(SunCertPathBuilder.java:141)
	at java.base/sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:126)
	at java.base/java.security.cert.CertPathBuilder.build(CertPathBuilder.java:297)
	at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:434)
Caused: sun.security.validator.ValidatorException: PKIX path building failed
	at java.base/sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:439)
	at java.base/sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:306)
	at java.base/sun.security.validator.Validator.validate(Validator.java:264)
	at java.base/sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:313)
	at java.base/sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:222)
	at java.base/sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:129)
	at java.base/sun.security.ssl.CertificateMessage$T13CertificateConsumer.checkServerCerts(CertificateMessage.java:1341)
Caused: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

아니 회사의 프록시 환경도 아닌데 왜 이런 에러가 나지? 해서 원인을 분석했더니

self signed certificate 라고 잡히네요.

#  curl https://google.com -v
*   Trying 12.34.56.78:443...
* Connected to google.com (12.34.56.78) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: self signed certificate
* Closing connection 0
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.se/docs/sslcerts.htmlcurl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

회사와 같이 프록시와 사내 인증서가 적용된 환경이 아닌데 왜 이런 현상이 발생하는지 계속 분석해보니

어떨때는 또 통신이 되기도 합니다.

그래서 무슨 차이인가 하여 traceroute를 시도해봤습니다.

정상적인 상황에서는 아래와 같이 통신을 하지만

# traceroute google.com
traceroute to google.com (172.217.25.174), 30 hops max, 60 byte packets
 1  12-34-56-78.etcd.kube-system.svc.cluster.local (12.34.56.78)  0.689 ms  0.579 ms  0.541 ms
 2  12.34.56.78 (12.34.56.78)  2.570 ms  2.532 ms  2.502 ms
 3  * * *
 4  100.82.171.49 (100.82.171.49)  1.135 ms 100.82.171.45 (100.82.171.45)  0.883 ms  0.844 ms
 5  10.67.252.254 (10.67.252.254)  1.199 ms 10.67.252.250 (10.67.252.250)  4.219 ms 10.67.252.254 (10.67.252.254)  1.131 ms
 6  10.222.35.212 (10.222.35.212)  2.253 ms 10.222.22.240 (10.222.22.240)  2.288 ms 10.222.18.160 (10.222.18.160)  1.949 ms
 7  10.222.8.175 (10.222.8.175)  4.351 ms 10.222.20.25 (10.222.20.25)  6.528 ms 10.222.23.203 (10.222.23.203)  2.034 ms
 8  72.14.203.90 (72.14.203.90)  30.108 ms 142.250.163.48 (142.250.163.48)  29.981 ms
 72.14.216.72 (72.14.216.72)  36.144 ms
 9  * * *
10  108.170.242.193 (108.170.242.193)  32.943 ms 108.170.242.129 (108.170.242.129)  35.381 ms 142.250.208.146 (142.250.208.146)  39.221 ms11  108.170.242.146 (108.170.242.146)  32.762 ms 108.170.242.209 (108.170.242.209)  39.643 ms 108.170.242.208 (108.170.242.208)  34.475 ms
12  209.85.246.213 (209.85.246.213)  36.130 msc 216.239.43.157 (216.239.43.157)  34.211 ms 209.85.241.107 (209.85.241.107)  34.799 ms
13  142.250.229.250 (142.250.229.250)  34.535 ms  37.353 ms sin01s16-in-f14.1e100.net (172.217.25.174)  29.530 ms

비정상적인 상황에서는 클러스터의 ip에서 통신이 멈춥니다

# traceroute google.com
traceroute to google.com (12.34.56.78), 30 hops max, 60 byte packets

아니 google.com의 IP가 왜 12.34.56.78이지??? 이상한 의문이 들어 172.217.25.174(제대로된 google.com의 IP)로

통신을 해보니 이건 또 잘되군요

여기에서 DNS 쪽이 뭔가 문제가 있구나 생각이 되어 확인을 해봤더니..

그게 원인이 맞았습니다.

/etc/resolv.conf의 내용을 보니 아래와 같이 되어 있는데

search infra-jenkins.svc.cluster.local svc.cluster.local cluster.local mycluster.internal

mycluster.internal 에 대한 nslookup 수행시 간헐적으로 master node의 ip가 리턴이 되고 있더군요

이에 대해 원인을 분석해보니

cluster 내부의 pod 들에게 ingress 설정을 위해 *.mycluster.internal 의 주소를 cluster의 master node의 IP로 하였더니

이로 인해 pod 내부에서 mycluster.internal에 대한 NXDOMAIN에 대한 DNS 쿼리 호출 시

mycluster.internal.mycluster.internal 로 접근을 시도 하였고 이를 다시 mater node의 IP로 반환이 되어

mater node에 있는 리버스 프록시 목적의 nginx 인증서를 사용하고 있었던 겁니다.

좀 어이 없는 상황이긴 한데.. pod 내부의 resolv.conf의 내용을 제대로된 도메인으로 접근할 수 있게

ns.mycluster.internal 로 변경하였습니다.

그랬더니 문제가 해결이 되네요.

좀 이상하게 해결되긴 했지만 통신이 잘되니.. 나중에 잊을 수 있는 트러블 슈팅 과정이라 이 과정을 남깁니다

저작자표시 비영리 변경금지

'인프라 관리 > ▷ Docker & Kubernetes' 카테고리의 다른 글

kubernetes에서 pod 할당 실패 (max pod limit error) (0)	2023.01.28
한글 적용된 ubuntu docker image (0)	2023.01.26
helm 사용법 (0)	2023.01.22
kubernetes에서 join을 위한 token 생성 (0)	2023.01.22
Kubernetes에 NFS Storage Class 선언하기 (nfs-subdir-external-provisioner) (0)	2023.01.22

내 블로그 - 관리자 홈 전환	`Q` `Q`
새 글 쓰기	`W` `W`

글 수정 (권한 있는 경우)	`E` `E`
댓글 영역으로 이동	`C` `C`

이 페이지의 URL 복사	`S` `S`
맨 위로 이동	`T` `T`
티스토리 홈 이동	`H` `H`
단축키 안내	`Shift` + `/` `⇧` + `/`

Software Sciense

POD내부에서 외부로 나가는 통신 시 self signed certificate 이슈가 발생한다면? (인증서 설정이 없음에도)

'인프라 관리 > ▷ Docker & Kubernetes' 카테고리의 다른 글

+ Recent posts

티스토리툴바

개인정보

단축키

내 블로그

블로그 게시글

모든 영역