[Dev] TLS Secret Sync Infra 개발

[bluejayA]

Describe the Story

- [ ] A clear and concise description of what this story is.

TKS-user Cluster SSL 도메인 인증서 배포를 위한 인프라 설치 및 설정

1. Git Hub에 Sealed Secret 올릴 Repo 설치
2. Sealed Secret 암호화할 공개키 쌍 확보호 TLS인증서 만듬 (100년짜리)
3. SSL Domain 인증서 확보
4. SSL Domain 인증서 Secret 생성 w/ +{color:#172b4d}[annotation : kubed.appscode.com/sync|http://kubed.appscode.com/sync]: "sync=taco-tls"{color}+
5. kubeseal로 2번에서 만든 인증서로 Sealed Secret생성. {{kubeseal --}}{{format}}{{=yaml --cert=sealed-secret-tls.ca < secret.yaml > sealed-secret.yaml}}
6. sealed-secret.yaml을 github repo에 올림
7. TKS-user Cluster CSI/CNI 설치 후 SSO 기본설정 후, Sealed Secrets Control를 2번 공개키로 설치
8. TKS-user Cluster에 Sealed Secret Controller 설치 후, kubed 설치
9. 6번 올린 Sealed Secrets를 kube-system ns에 설치

위 설치는 Ingress controller 설치전 완료 하고, domain 인증서를 사용할 NS는 생성 시,

sync=taco-tls label을 붙임

Acceptance criteria (Validation Scenario)

- [ ] This is something that can be verified to show that this story is satisfied.
- [ ] This should have information for QA to validate this story.

Additional information (Optional)

[robertchoi80]

성일님과 상의해서 범위 조정 필요

[robertchoi80]

내일 싱크시 문의

• 2번은 이미 존재하는 secret 내에서 인증서 부분을 추출해서 그냥 쓰는 것이 아닌지?
  • 우선 default로 유효기간 10년짜리로 만들어지는 것 확인.
• 3번, user service를 위한 domain 인증서를 secret으로 만들어주는 주체는 누구인가? 인증서 발급부터 secret으로 만들어지기까지의 과정?? -> user service용은 user가 알아서 repo 에 업로드/ 우선 taco service용 domain 인증서 먼저 해결
• 도메인 인증서는 cluster 당 하나인가? repo 위치는 기존의 tks-management 내의 디렉토리에 넣는 것은 어떤지? (디렉토리 구조 설계 필요) -> 우선 taco service용 인증서 먼저 mgmt cluster용 repo에 올릴 것
• 본 task 로직은 https://github.com/openinfradev/tks-flow/blob/main/tks-cluster/create-usercluster-wftpl.yaml 에 넣으면 되는가? -> taco service용 인증서는 mgmt deploy script 에서 처리??

[robertchoi80]

우선 TKS bastion 노드에서 수동으로 다음 내용 진행해봄

# sealed-secret controller 설치 #
wget https://github.com/bitnami-labs/sealed-secrets/releases/download/v0.12.1/controller.yaml
kubectl apply -f controller.yaml

# (향후 sealing 에 사용하기 위해) controller로부터 인증서 추출 #
kubectl get secret -n kube-system -l sealedsecrets.bitnami.com/sealed-secrets-key -o jsonpath="{.items[0].data.tls\.crt}" | base64 -d > sealed-secret-tls.ca

# taco-cat 도메인 인증서 secret 획득 #
kubectl get secret taco-cat-tls -n argo -o yaml > taco-cat-tls.yml

# taco-cat 인증서 secret을 seal #
kubeseal --format=yaml --cert=sealed-secret-tls.ca < taco-cat-tls.yml > sealed-taco-cat-tls.yaml

seal된 secret을 tks-admin-site 에 테스트 차원에서 업로드
https://github.com/openinfradev/tks-admin-site/blob/main/sealed-certificates/taco-cat-tls-sealed.yaml

controller가 사용하는 master key 도 계속 사용되므로 admin-site repo 에 올려두고 controller 설치 전에 미리 secret으로 생성해두어야함.
https://github.com/openinfradev/tks-admin-site/blob/main/sealed-secret-key/master-key-secret.yaml

mgmt cluster 설치가 자동화된다면 contoller 설치 및 secret 배포는 다음과 같이 가능할 것 같음.
'deploy-cert-on-mgmt' 등의 workflow 만들고,

     ## sealed-secret-master-key 설치 ##


     ## AppGroupOnAdmin task 호출해서 controller 설치 ##
     - name: install-sealed-secret-controller
        templateRef:
          name: tks-create-application
          template: AppGroupOnAdmin
        arguments:
          parameters: 
          - name: list
            value: |
              [
                 { "path": “sealed-secret-controller", "namespace": “kube-system” },
                 { "path": “kubed", "namespace": “kube-system” },
                  ...
              ]

    ## Get sealed secret from git repo and deploy it to cluster ##

[robertchoi80]

PR 제출 완료!
openinfradev/tks-flow#11

admin cluster와 user cluster 의 경우 배포시 로직이 조금 달라서, workflow를 분리해서 작성함.
usercluster에 배포시 호출하는 tks-createapp workflow가 기본 createapp workflow와 통합되면, 이를 호출하는 workflow도 admin, user cluster 구분 없이 통합 가능할 것으로 보임.

tks-createapp의 경우 우선은 createapp과 변수명 등만 통일하였고, 차주 데모 완료후 본격적으로 통합 예정임.

본 티켓은 여기서 종료!