Teleport란 무엇인가?
텔레포트는 원래 인프라 접근을 위해 인증서 기반으로 사용자를 관리하는 솔루션인데 쿠버네티스에서 사용할 수 있다. 실제로 현업에서도 많이 쓰기도 하고, 재택을 많이 차용하는 기업에서 사용하기도 하고, devops팀이 크면 클수록 많이 사용하는 것 같다. 나는 힘없고 돈없는 개인 개발자이기에 유료버전은 사용하지 않고 커뮤니티 버전으로 설치할 거다.
근데 내가 왜 굳이 텔레포트를 쓰냐?
내가 올린 Minikube를 생각해보면 EC2인스턴스에 Docker 드라이버를 백앤드로해서 Minikube를 올렸다. 그러면 내가 앞으로 개발할 때는 여기 EC2인스턴스에 SSH가 되었든 클라우드 쉘이 되었든 접속해서 붙어서 CLI 환경에서만 작업을 해야 하는 것인가?(물론 VSCode로 remote ssh로 붙어서 사용해도 되지만...)
나는 로컬에서 서비스를 개발하고 싶다는 이말이다.
Local에서 사용하게 되면 얻는 이점이 여러가지가 있다.
- OpenLens같은 Kubernetes tools를 사용할 수 있다.
- ssh key가 없어도 되므로 보안성이 높아진다.
- OS에 자유로워진다.
여러가지가 있지만 일단 내가 얻을 수 있는 이점은 이렇게 있다. 그리고 텔레포트를 설치하면서 알게되는 여러가지 개념들이 복기하기도 좋고 향후에 어떻게 될지 모르지만 Teleport를 써봤다고 말할 수도 있어서 , 그리고 이게 생각보다 설치가 너무 어려워 나같은 실수를 하지 않았으면 해서 등등 여러가지 차원에서 텔레포트를 사용하게 되었다.
텔레포트 설치 방법
- EKS에서 IRSA로 TeportCluster를 올려서 사용하는 방법
- Bastion서버에 TeleportCluster를 올려두고 거기에서 Minikube를 인증하는 방법
이 있지만 나는 두번째 방법을 응용(?)해서 사용하기로 하겠다. 텔레포트는 기본적으로 도메인이 필요한데 도메인을 구입하도록 하자. 구매한 도메인은 앞으로 편의상 보안상 abc.com으로 바꿔서 부르기로 하겠다.
첫번째 작업이다. AWS > Route53에서 abc.com으로 domain영역을 만들자. Route53에서 만들어진 NS를 본인이 구매한 domain에서 네임서버관리(?) 이런 비슷한 이름이 있을 것인데 여기에 그대로 넣자.
이제 abc.com에 sub도메인을 넣자. 왜냐하면 지금은 개발서버인데 나중에 운영도 할거 아닌가? 그 때를 대비해서다. 운영서버는 abc.com으로 운영하고, 개발서버는 dev.abc.com으로 운영하려고 하면 아주 깔끔하니까 말이다.
Route53에서 dev.abc.com이라는 호스팅영역을 만들고 여기에서 만들어진 NS를 Route53에 있는 abc.com에 추가한다.
이제 dev.abc.com도 사용가능하게 되었다. 아직 끝이 아니다 ㅠㅠ. 개발서버에 텔레포트를 붙여야 하기때문에 teleport.dev.abc.com도 호스팅영역을 만들어 같을 작업을 하자.
teleport.dev.abc.com의 NS를 dev.abc.com에 추가해야한다.
이렇게 하면 도메인 세팅은 완료된거다.
텔레포트는 인증서가 필요하다.
텔레포트는 SSL 인증서가 필요하다. 근데 우리는 그 것이 없지 않은가? AWS Certificate Manager에서 돈내고 받아도된다. (1년에 40만원이었던가?) 무료로 무엇인갈 하기위해서는 노력이 많이 필요하다. 그래서 인증서 발급을 도와주는 Cert-manager를 사용하겠다. 다이렉트로 설치해도 되지만 Minikube도 올려두었겠다. Minikube를 이용해서 CertManager를 설치하겠다.
Helm
Kubernetes Helm은 Kubernetes 애플리케이션을 쉽게 패키징하고 배포하는 도구인데, 차트 / 패키지관리 / 버전 관리 / 템플릿 버전 등 여러가지로 필수이다. Devops나 Kubernetes를 사용한다고 하면 Helm은 거의 업계 필수이니 꼭 공부해두도록하자.
$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
$ chmod 700 get_helm.sh
$ ./get_helm.sh
$ rm ./get_helm.sh
$ helm version
version.BuildInfo{Version:"v3.16.2", # GitCommit:"13654a52f7c70a143b1dd51416d633e1071faffb", GitTreeState:"clean", GoVersion:"go1.22.7"}
helm이 설치되었으면 이제 cert-manager를 설치한다.
$ helm repo add jetstack https://charts.jetstack.io --force-update
$ helm upgrade \
--install \
cert-manager jetstack/cert-manager \
--namespace cert-manager \
--create-namespace \
--version v1.16.1 \
--set crds.enabled=true \
--set 'extraArgs={--dns01-recursive-nameservers-only,--dns01-recursive-nameservers=8.8.8.8:53\,1.1.1.1:53}'
$ kubectl get all -n cert-manager
NAME READY STATUS RESTARTS AGE
pod/cert-manager-55c69bf5cf-4fr8k 1/1 Running 0 56s
pod/cert-manager-cainjector-5765b5f544-qhgbc 1/1 Running 0 56s
pod/cert-manager-webhook-6b67444dc9-lc2xf 1/1 Running 0 56s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/cert-manager ClusterIP 10.99.82.208 <none> 9402/TCP 57s
service/cert-manager-cainjector ClusterIP 10.96.38.85 <none> 9402/TCP 57s
service/cert-manager-webhook ClusterIP 10.102.0.11 <none> 443/TCP,9402/TCP 57s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/cert-manager 1/1 1 1 57s
deployment.apps/cert-manager-cainjector 1/1 1 1 57s
deployment.apps/cert-manager-webhook 1/1 1 1 57s
NAME DESIRED CURRENT READY AGE
replicaset.apps/cert-manager-55c69bf5cf 1 1 1 56s
replicaset.apps/cert-manager-cainjector-5765b5f544 1 1 1 56s
replicaset.apps/cert-manager-webhook-6b67444dc9 1 1 1 56s
cert-manager가 정상적으로 설치되었다. 이제 인증서를 발급 받아야 하는데 준비물이 필요하다.
- AWS_ACCESS_KEY_ID
- AWS_SECRET_ACCESS_KEY
- HostedZoneId(teleport.dev.abc.com)
AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY는 AWS IAM에서 발급받을 수 있고, HostedZoneId는 Route53에서 호스팅영역에서 확인할 수 있다.
$ kubectl apply -f - <<EOF
apiVersion: v1
stringData:
AWS_ACCESS_KEY_ID: <AWS_ACCESS_KEY_ID>
AWS_SECRET_ACCESS_KEY: <AWS_SECRET_ACCESS_KEY>
kind: Secret
metadata:
name: route53-credentials-secret
namespace: cert-manager
type: Opaque
EOF
Secret을 만들었으면 ClusterIssuer와 Certificate를 만들어주자. 오직 teleport만들 위한 인증서다. 다른것은 전부 AWS Certificate Manager를 사용할거다.
- hostedZoneID
를 본인에 맞게 수정한 후 적용하자.
$ kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-clusterissuer
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
email: ggorockee@gmail.com
privateKeySecretRef:
name: cert-for-teleport
solvers:
- dns01:
route53:
region: ap-northeast-2
hostedZoneID: Z015492137Y5RQP12BTUJ
accessKeyIDSecretRef:
name: route53-credentials-secret
key: AWS_ACCESS_KEY_ID
secretAccessKeySecretRef:
name: route53-credentials-secret
key: AWS_SECRET_ACCESS_KEY
EOF
$ kubectl get clusterissuer
NAME READY AGE
letsencrypt-clusterissuer True 17s
ClusterIssuer가 True가 되었으니 이제 Certificate를 만들어줄 차례다. Certificate는 namespace의 영향을 받기 때문에 먼저 namespace부터 만들어주도록하겠다.
$ kubectl create ns teleport
namespace를 만들고나면 Certificate를 발급받으면된다.
주의해야할 사항은
commonName에는 Route53에서 만든 호스팅영역이다. 나의 경우 teleport.dev.abc.com이 된다.
그리고 dnsNames 여기도 중요하다. 여기에는 2가지 값이 순서대로 들어가야 한다. wildcard 도메인을 2번째에 써줘야 한다. 그렇지 않으면 cert-manager가 버그가 일어날 수도 있다.
$ kubectl apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: letsencrypt-cert
namespace: teleport
spec:
secretName: teleport-tls
commonName: teleport.dev.abc.com
dnsNames:
- "teleport.dev.abc.com"
- "*.teleport.dev.abc.com"
issuerRef:
name: letsencrypt-clusterissuer
kind: ClusterIssuer
EOF
시간이 좀 지나고 나면 Ready 상태가 True로 된다. 만약 이 부분에서 에러가 나면 describe로 확인해보자.
$ kubectl get certificate -n teleport
NAME READY SECRET AGE
letsencrypt-cert True teleport-tls 6m56s
인증서가 발급되었으니 이 인증서를 파일로 저장하면 된다.
$ kubectl describe secret/teleport-tls -n teleport
Name: teleport-tls
Namespace: teleport
Labels: controller.cert-manager.io/fao=true
Type: kubernetes.io/tls
Data
====
tls.crt: 3647 bytes
tls.key: 1679 bytes
tls.crt의 값을 base64 decoding하여 /home/ubuntu/fullchain.pem 으로 저장하고
tls.key의 값을 decoding해서 /home/ubuntu/privkey.pem 으로 저장하자.
일단 여기까지 됐으면 8할은 된거다. 이부분에서 꼬이면 아무것도 되지 않는다. ㅠㅠ 일단 이번 포스트는 여기까지 하는 걸루..
'devops > minikube' 카테고리의 다른 글
6. Istio: 서비스 메쉬의 선두주자 (25) | 2024.11.19 |
---|---|
5. Connect to Minikube Cluster via Teleport(3) (25) | 2024.11.19 |
4. Connect to Minikube Cluster via Teleport(2) (24) | 2024.11.19 |
2. Minikube on EC2 (25) | 2024.11.19 |
1. EKS는 너무 비싸다 (2) | 2024.11.19 |