작성
·
386
0
답변 3
0
올려주신 스크린샷에서 configmap 업데이트가 필요할 것 같습니다.
깃허브에 올려둔 레포에서, kubernetes/create-cluster.yaml 코드를 확인해보시면 아래처럼 구성이 되어있습니다.
올려주신 스크린샷에는, github-actions이라는 role이 있는데 configmap 에는 반영되어 있지 않습니다.
configmap을 편집해서 아래 내용을 추가해주셔야할 것 같습니다.
kubectl edit cm aws-auth -n kube-system 커맨드를 통해, 아래 포맷에 맞춰서 적절한 값으로 넣고
다시 시도해보시겠어요 ? (기존 값은 유지된 상태로 작업하셔야합니다)
mapRoles: |
- "groups":
- "system:masters"
"rolearn": "arn:aws:iam::${ACCOUNT_NAME}:role/github-actions"
"username": "actions"
이런 구조로 해야한다는 뜻으로 이해해주시면 될 것 같습니다.
0
답변 감사합니다.
Bastion host에서 github actions role이 정의 되어 있음을 확인했고
EKS 클러스터의 API server endpoint access도 강사님과 같이 Public입니다..
혹시 이 외에 수정이 필요할 수도 있는 부분이 있을까요?
0
안녕하세요 ynmj님
현재 구성하신 인프라를 확인할 수가 없어서 말씀해주신 내용 바탕으로
답변드리겠습니다.
A. IAM 신뢰 관계
Github Actions이 사용하기 위해 구성한 IAM Role이 명확히 설정되었는 지 확인이 필요합니다.
deploy단계까지 진행되었다는 건, 그 전에 이미 aws-actions/configure-aws-credentials@v4
액션을 사용했다는 것으로 판단됩니다. (OIDC 설정 적용)
그래서, 사용하는 IAM Role에서 신뢰관계(trust_relationships) 설정이 올바르게 되어있는 지 해봐야할 것 같습니다.
Bastion host에서, kubectl get cm aws-auth -n kube-system -o yaml 커맨드를 통해
github actions role이 정의되어 있는 지도 확인이 필요합니다.
B. 환경의 차이
만약 A가 올바르게 구성되어 있다면, 말씀하신 환경의 차이일 가능성이 높습니다.
강의에서는 Cloud9에서 Cloudformation으로 EKS를 프로비저닝하는 방식을 사용합니다.
만약, EKS의 API server endpoint access가 public 으로 구성되어 있다면
깃헙액션이 OIDC를 통해 AWS에 연결하고, 올바른 IAM 권한과 신뢰관계가 설정되어 있다면
EKS클러스터에 액세스할 수 있습니다.
그런데, 이 부분이 private으로 구성되어 있다면 조금 복잡해집니다.
이 경우, 깃헙액션의 IP 대역을 허용하거나 (깃헙 엔터프라이즈가 아닌 경우 고정IP할당이 안됩니다)
아니면 깃헙액션이 제공해주는 runner가 아닌 self-hosted runner를 사용하는 방식으로 구성해야 합니다.
EC2 인스턴스를 self-hosted runner로 구성하거나 혹은 ARC (Action Runner Controller) 를 사용해서
쿠버네티스의 파드로 깃헙액션 잡을 실행할 수 있도록 구성해야합니다.
EKS의 API server endpoint access가 다를 것이라고 추측하고 있는데, 맞는 지 모르겠네요 .
다른 인프라 구성이면 그에 맞는 설정을 하기 위해서, 추가되는 변경사항이 많기 때문에
강의를 학습하시기 위해서는 Cloud9에서 Cloudformation으로
프로비저닝 하시기를 권장드립니다.