<div id="readability-page-1" class="page"><div>
 <a href="/m/category/DevOps/Cert%20Manager">DevOps/Cert Manager</a><h3>[Cert manager] 서비스 도메인 svc.cluster.local 과 HTTPS 통신하기</h3>
 </div><cite>KoB</cite>
 2024. 2. 5. 21:06
 <div>
 

쿠버네티스 내부끼리 통신을 할 때 보통 서비스의 도메인 svc.cluster.local 을 이용하여 통신하게 됩니다.

외부에서 내부로 들어오는 통신에 대해서는 Ingress 를 이용해 https 통신을 하게되죠.

하지만 Ingress 는 내부 통신에 대해서는 https 통신을 보장해주진 않죠. 이 부분에 대해서는 Istio 의 mTLS 를 이용해서 파드와의 통신은 모두 https 통신을 하게 할 수 있습니다.
<blockquote data-ke-style="style2">Istio 의 mTLS 가 궁금하다면? <a href="https://kingofbackend.tistory.com/265" target="_blank" rel="noopener">[Istio] 쉿! 우리만의 비밀이야 - mTLS (확인편)</a> <a title="[Istio] 쉿! 우리만의 비밀이야 - mTLS (검증편)" href="https://kingofbackend.tistory.com/270" target="_blank" rel="noopener">[Istio]&nbsp;쉿!&nbsp;우리만의&nbsp;비밀이야&nbsp;-&nbsp;mTLS&nbsp;(검증편)</a></blockquote>

그렇다면 mTLS 를 이용하지 않고 내부 통신은 어떻게 https 통신을 할 수 있을까요?

정답은 간단합니다. 파드 마다 certificate 를 가지고 있으면 됩니다.&nbsp;

이번 글에서는 서비스를 생성할 때 coreDNS 에 등록되는 svc.cluster.local 도메인에 https 통신을 해보고자 합니다.

렛츠두더코드~
<figure data-ke-mobilestyle="widthOrigin" data-filename="로켓-렛츠.png" data-origin-width="453" data-origin-height="395">
 
 <img src="https://blog.kakaocdn.net/dn/1Y4eZ/btsEnV0TOeZ/o2Bbdf9jcaS7pQXizp1upK/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-filename="로켓-렛츠.png" data-origin-width="453" data-origin-height="395">
 
 
</figure>


Cert Manager 를 이용해서 certificate 를 생성합니다.
<blockquote data-ke-style="style2">Cert Manager 가 궁금하다면 여기 <a href="https://kingofbackend.tistory.com/category/DevOps/Cert%20Manager" target="_blank" rel="noopener">참고!</a></blockquote>

Issuer 와 Certificate 를 아래와 같아요.
<pre id="code_1707133677476" data-ke-language="html" data-ke-type="codeblock"><code>apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
 name: service-https-test
 namespace: default
spec:
 selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
 name: service-https-test
 namespace: default
spec:
 dnsNames:
 - service-https-test.default.svc
 - service-https-test.default.svc.cluster.local
 issuerRef:
 kind: Issuer
 name: service-https-test
 secretName: service-https-test</code></pre>

svc.cluster.local 의 소유자가 아니니 selfSigned 를 통해 Certificate 를 생성합니다.

최종적으로 Certificate 는 Secret 으로 생성됩니다.
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="1438" data-origin-height="1203">
 
 <img src="https://blog.kakaocdn.net/dn/cqAfrr/btsEnbo1pcd/1e5nV45I6RiCMNKPH1dYNk/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="1438" data-origin-height="1203">
 
 <figcaption>Certificate 로 생성된 Secret</figcaption>
</figure>

ca.crt, tls.crt, tls.key 가 생성됩니다. 디코딩 해보면 아래와 같죠.
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="1117" data-origin-height="973">
 
 <img src="https://blog.kakaocdn.net/dn/lBftI/btsEmREkDaA/DnRHHkrwptzbGKpkLu1aDk/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="1117" data-origin-height="973">
 
 <figcaption>ca.crt</figcaption>
</figure>


Cert Manager 를 이용하니 확실히 편합니다. 없이 한다면 ssh-keygen 로 생성해서 하나하나 Secret 값으로 넣어줬어야 했을 겁니다.

그 다음으로 nginx 에서 사용할 config 를 configmap 을 이용해 생성합니다.
<pre id="code_1707134067237" data-ke-language="html" data-ke-type="codeblock"><code>apiVersion: v1
kind: ConfigMap
metadata:
 name: service-https-test
 namespace: default
data:
 nginx-tls.conf: |
 server {
 listen 80;
 server_name _;
 return 301 https://$host$request_uri;
 }
 
 server {
 listen 443 ssl;
 server_name _;
 
 ssl_certificate /etc/nginx/ssl/tls.crt;
 ssl_certificate_key /etc/nginx/ssl/tls.key;
 
 location / {
 root /usr/share/nginx/html;
 index index.html;
 }
 }</code></pre>

80 포트로 접근하게 되면, 443 포트로 리다이렉션 되게끔 구성하였고, server_name 을&nbsp; _; 으로 설정함으로써 아무 도메인이나 다 수용합니다.

그리고 이제 서비스와 파드를 생성합니다.
<pre id="code_1707134133244" data-ke-language="html" data-ke-type="codeblock"><code>apiVersion: v1
kind: Service
metadata:
 name: service-https-test
 namespace: default
spec:
 ports:
 - name: http
 port: 80
 targetPort: 80
 - name: https
 port: 443
 targetPort: 443
 selector:
 app: service-https-test
 sessionAffinity: None
 type: ClusterIP
 ---
apiVersion: v1
kind: Pod
metadata:
 labels:
 app: service-https-test
 name: nginx
 namespace: default
spec:
 containers:
 - image: nginx
 name: nginx
 volumeMounts:
 - name: nginx-config
 mountPath: /etc/nginx/conf.d
 - name: nginx-certs
 mountPath: /etc/nginx/ssl
 volumes:
 - name: nginx-config
 configMap:
 name: service-https-test
 - name: nginx-certs
 secret:
 secretName: service-https-test</code></pre>

어려운 부분이 없으니 따로 설명은 하지 않겠습니다.

그럼 이제 한번 확인해보죠!

서비스의 도메인인 http://service-https-test:80 으로 접근하니 리다이렉션 된 것을 확인 할 수 있습니다.
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="682" data-origin-height="556">
 
 <img src="https://blog.kakaocdn.net/dn/bHrIXi/btsEndtBlCY/SUncKeIV0AV4XXhnxNWlh1/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="682" data-origin-height="556">
 
 <figcaption>http://service-https-test:80</figcaption>
</figure>

<blockquote data-ke-style="style3">Nginx 가 사용하는 인증서는 자체 사인한 인증서이기 때문에 curl 명령어를 사용할 때 -k 를 붙여줘야 합니다.</blockquote>


이번에는 https://service-https-test:443 로 접근해서 https 통신을 하는 지 확인해보겠습니다.
TLS handshake 과정이 있는 걸 보니 아주 잘 동작합니다.&nbsp;
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="936" data-origin-height="1334">
 
 <img src="https://blog.kakaocdn.net/dn/csekzi/btsEqvmH8FI/mQvIxkODdRsLGYtgW8IPGk/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="936" data-origin-height="1334">
 
 <figcaption>https://service-https-test:443</figcaption>
</figure>


뿐만 아니라, 파드의 IP 주소인 https://10.42.0.10:443 로도 가능합니다.&nbsp;
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="852" data-origin-height="1294">
 
 <img src="https://blog.kakaocdn.net/dn/zK28L/btsEoq7szcf/3O2TdrhWrLxmtAeOxXLKaK/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="852" data-origin-height="1294">
 
 <figcaption>https://10.42.0.10:443</figcaption>
</figure>

그리고 당연하겠지만, 포트 포워딩으로 접근해도 가능합니다.
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="564" data-origin-height="293">
 
 <img src="https://blog.kakaocdn.net/dn/by7l57/btsEm78nIj1/JpaJrwPpqvjoguPuUHv0F0/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="564" data-origin-height="293">
 
 <figcaption>localhost</figcaption>
</figure>

주의 요함이 뜨는데, 그건 인증서가 정식 CA 가 아닌 자체 사인한 인증서이기 때문입니다.
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="535" data-origin-height="573">
 
 <img src="https://blog.kakaocdn.net/dn/csQcGF/btsEoq7sBEh/pYTEsNJjOYlP48K70dGQD1/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="535" data-origin-height="573">
 
 <figcaption>인증서</figcaption>
</figure>

mTLS 를 이용하기 때문에 svc.cluster.local 에 대한 https 통신이 필요는 없었지만, 항상 궁금했던 부분이였는데 이번 실습으로 통해 궁금증을 해결할 수 있었습니다.

그럼 오늘은 여기까지~
<figure data-ke-mobilestyle="widthOrigin" data-filename="로켓-따봉.png" data-origin-width="573" data-origin-height="388">
 
 <img src="https://blog.kakaocdn.net/dn/OTyO1/btsEoJZTybD/HzFQoMKf2ua0S5nBtp3fF1/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-filename="로켓-따봉.png" data-origin-width="573" data-origin-height="388">
 
 
</figure>
 
 
 </div></div>

King of Back-end

쿠버네티스 내부끼리 통신을 할 때 보통 서비스의 도메인 svc.cluster.local 을 이용하여 통신하게 됩니다.
 
외부에서 내부로 들어오는 통신에 대해서는 Ingress 를 이용해 https 통신을 하게되죠.
 
하지만 Ingress 는 내부 통신에 대해서는 https 통신을 보장해주진 않죠. 이 부분에 대해서는 Istio 의 mTLS 를 이용해서 파드와의 통신은 모두 https 통신을 하게 할 수 있습니다.
Istio 의 mTLS 가 궁금하다면?
[Istio] 쉿! 우리만의 비밀이야 - mTLS (확인편)
[Istio] 쉿! 우리만의 비밀이야 - mTLS (검증편)
 
그렇다면 mTLS 를 이용하지 않고 내부 통신은 어떻게 https 통신을 할 수 있을까요?
 
정답은 간단합니다. 파드 마다 certificate 를 가지고 있으면 됩니다. 
 
이번 글에서는 서비스를 생성할 때 coreDNS 에 등록되는 svc.cluster.local 도메인에 https 통신을 해보고자 합니다.
 
렛츠두더코드~
 
 
Cert Manager 를 이용해서 certificate 를 생성합니다.
Cert Manager 가 궁금하다면 여기 참고!
 
Issuer 와 Certificate 를 아래와 같아요.
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: service-https-test
  namespace: default
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: service-https-test
  namespace: default
spec:
  dnsNames:
    - service-https-test.default.svc
    - service-https-test.default.svc.cluster.local
  issuerRef:
    kind: Issuer
    name: service-https-test
  secretName: service-https-test
 
svc.cluster.local 의 소유자가 아니니 selfSigned 를 통해 Certificate 를 생성합니다.
 
최종적으로 Certificate 는 Secret 으로 생성됩니다.
 
ca.crt, tls.crt, tls.key 가 생성됩니다. 디코딩 해보면 아래와 같죠.
 
 
Cert Manager 를 이용하니 확실히 편합니다. 없이 한다면 ssh-keygen 로 생성해서 하나하나 Secret 값으로 넣어줬어야 했을 겁니다.
 
그 다음으로 nginx 에서 사용할 config 를 configmap 을 이용해 생성합니다.
apiVersion: v1
kind: ConfigMap
metadata:
  name: service-https-test
  namespace: default
data:
  nginx-tls.conf: |
    server {
      listen              80;
      server_name         _;
      return 301 https://$host$request_uri;
    }
    
    server {
      listen              443 ssl;
      server_name         _;
    
      ssl_certificate     /etc/nginx/ssl/tls.crt;
      ssl_certificate_key /etc/nginx/ssl/tls.key;
    
      location / {
        root   /usr/share/nginx/html;
        index  index.html;
      }
    }
 
80 포트로 접근하게 되면, 443 포트로 리다이렉션 되게끔 구성하였고, server_name 을  _; 으로 설정함으로써 아무 도메인이나 다 수용합니다.
 
그리고 이제 서비스와 파드를 생성합니다.
apiVersion: v1
kind: Service
metadata:
  name: service-https-test
  namespace: default
spec:
  ports:
    - name: http
      port: 80
      targetPort: 80
    - name: https
      port: 443
      targetPort: 443
  selector:
    app: service-https-test
  sessionAffinity: None
  type: ClusterIP
  ---
apiVersion: v1
kind: Pod
metadata:
  labels:
    app: service-https-test
  name: nginx
  namespace: default
spec:
  containers:
    - image: nginx
      name: nginx
      volumeMounts:
        - name: nginx-config
          mountPath: /etc/nginx/conf.d
        - name: nginx-certs
          mountPath: /etc/nginx/ssl
  volumes:
    - name: nginx-config
      configMap:
        name: service-https-test
    - name: nginx-certs
      secret:
        secretName: service-https-test
 
어려운 부분이 없으니 따로 설명은 하지 않겠습니다.
 
그럼 이제 한번 확인해보죠!
 
서비스의 도메인인 http://service-https-test:80 으로 접근하니 리다이렉션 된 것을 확인 할 수 있습니다.
 
Nginx 가 사용하는 인증서는 자체 사인한 인증서이기 때문에 curl 명령어를 사용할 때 -k 를 붙여줘야 합니다.
 
 
이번에는 https://service-https-test:443 로 접근해서 https 통신을 하는 지 확인해보겠습니다.
TLS handshake 과정이 있는 걸 보니 아주 잘 동작합니다. 
 
 
뿐만 아니라, 파드의 IP 주소인 https://10.42.0.10:443 로도 가능합니다. 
 
그리고 당연하겠지만, 포트 포워딩으로 접근해도 가능합니다.
 
주의 요함이 뜨는데, 그건 인증서가 정식 CA 가 아닌 자체 사인한 인증서이기 때문입니다.
 
mTLS 를 이용하기 때문에 svc.cluster.local 에 대한 https 통신이 필요는 없었지만, 항상 궁금했던 부분이였는데 이번 실습으로 통해 궁금증을 해결할 수 있었습니다.
 
그럼 오늘은 여기까지~

[Cert manager] 서비스 도메인 svc.cluster.local 과 HTTPS 통신하기

댓글