wrong aws-auth - (Forbidden): pods is forbidden

AWSKRUG 슬랙에서
질의응답 중에서 유용한 내용을 수정 보강해서 올려봅니다.

TL;DR

- EKS 의 인증 설정인 aws-auth 을 잘못 구성해서, Forbidden 에러 발생하면 어떻게 하지?
- 다시 셋업한다.
- AWS support 요청하고 손 빨고 있는다.
- 개구멍을 찾아서, 고쳐본다.

aws-auth 는 Amazon EKS에는 인증 정보를 구성하는 configmap 이다. 근데 이걸 잘못 설정하면 클러스터를 조작할 수 없는 문제를 겪을 수 있다. 이 때문에 원성이 많은 것 같다. 고쳐주시겠지. ^^;

원래 문제는 이렇다.

eks 업그레이드 후 k8s api 인증 문제를 겪고 있는데요. 관련해서 해결방안을 고민해보신 분 계실까요?
eks, kubectl cli -> 업그레이드, aws-iam-authenticator -> 최신
버전겪는 문제
-> kubectl 명령어로 아무것도 수행 못 함;;  아래와 같이 에러가 발생합니다.

Error from server (Forbidden): pods is forbidden:
 User "XXX" cannot list resource "pods" in API group "" in the namespace "default"​

유추하는 문제는… auth-config 설정할 때 아래처럼 했는데요(XXX 로 바꿈).

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::445363019552:role/worker
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
    - rolearn: arn:aws:iam::445363019552:role/admin
      username: XXX
      groups:
        - system:masters​

아래 role은 애초에 eks를 생성한 role입니다.

arn:aws:iam::445363019552:role/admin

이걸 kubectl 명령 자체가 안되고 관련 api 호출 할 방법이 없으니, 실제로 configmap / cluster role 업데이트 할 방법이 없네요;;;

문제가 있으니, 일단 troube-shooting page 를 살펴보자. 사실 이전끼자만 해도, 이 문제의 해결책은 보통 클러스터 다시 설치하시오로 알고 있었다(그게 빠르고 편하니까...) 물론 질문하신 분은 이미 보셨을듯 하지만 돌다리도 두드려 보게 다시, 확인해보는 것이 좋다. 하지만, 제목부터 오타다. 기계 번역이라지만, 제목부터 Amazon EK 문제해결이라뉘(AWS에 피드백 줬다).

내용을 보니, 권한이 없거나 액세스가 거부됨(kubectl) 이 그나마 근접해 보이지만, 에러 메시지가 다르다. 우리껀 Forbidden 이고, 여긴 Unauthorized 이다. 여기엔 해결책이 없었다.

어느 분의 조언에 따라, RBAC 권한이 빠진지 알아보았다.

$ kubectl auth can-i --list
Resources                                       Non-Resource URLs   Resource Names     Verbs
selfsubjectaccessreviews.authorization.k8s.io   []                  []                 [create]
selfsubjectrulesreviews.authorization.k8s.io    []                  []                 [create]
                                                [/api/*]            []                 [get]
                                                [/api]              []                 [get]
                                                [/apis/*]           []                 [get]
                                                [/apis]             []                 [get]
                                                [/healthz]          []                 [get]
                                                [/healthz]          []                 [get]
                                                [/livez]            []                 [get]
                                                [/livez]            []                 [get]
                                                [/openapi/*]        []                 [get]
                                                [/openapi]          []                 [get]
                                                [/readyz]           []                 [get]
                                                [/readyz]           []                 [get]
                                                [/version/]         []                 [get]
                                                [/version/]         []                 [get]
                                                [/version]          []                 [get]
                                                [/version]          []                 [get]
podsecuritypolicies.policy                      []                  [eks.privileged]   [use​

 

빠졌다. 깨끗하게 다 빠졌다.
그러니까, 질문자의 이야기처럼 아무런 권한도 없으니 해결할 수도 없다. 이렇게 망한 건가?
아무리 쉽게 만들고 뽀개는 클라우드라지만, 그냥 막 망가뜨리기는 싫다. 어떻게 할까? 좀 더 찾아보자.
찾아보니, 이런 문제를 일부 몇 사람만 겪는 것일까? 아니다! 스택오버플로만 봐도 1000번 넘게 찾아본 것을 보면, 꽤 많은 분들이 고생하고 있다는 것이다.

2년 전부터라뉘, 그럼 이 문제를 고쳐달라고 하는 사람은 없을까? 아마존은 개발 로드맵을 공개하였고, 여기서 기능 개선 등을 요청할 수 있다. 사실 이런 점이 아마존의 좋은 점이라 할 수 있다.

https://github.com/aws/containers-roadmap/issues/1209
어서, 👍 를 눌러주자. 홀로 겪는 문제가 아닌듯 하다. 나도 눌러본다.

AWS support 요청하고 손 빨고 있는다.

그리고 여기에서 문제 해결의 희망을 찾았다! 

AWS support 로 해결 가능하다는 고백이 아닌가! 아마도 AWS에서는 매니지드 마스터노드에 직접 접속이 가능할거니까? 이건 알 수 없지만... 가능하단다. 하지만, 기다리며 손 빨고 있기는 싫다. 그렇다고 밀고 다시 설치하기도 싫다.

일단, clusterrole 이라도 부여해줄 수 있는 그런 권한 많은 곳은 없을까? 사실 이건 나름 백도어인데,  보안을 위해, 최소 필요 권한을 추구하니까, 백도어라고 할까 하는 것들은 다 막혀있다. 그럼에도 어떻게 뚫어 볼 것인가?

1. kube-dashboard 를 이용하면 어떨까? 다행이 설치는 하였지만, 그게 장식품과 같이 권한이 없다.
2. 그럼 운영중인 파드에 들어가서, 처리하면 어떨까? RBAC 권한을 많이 부여받은 파드에 말이다.

파드 이름을 안다고 그 안에 들어갈 수는 있는가? 사실 알수도 없지만, kubectl exec 같은 것도 안된다.

개구멍 찾아서 고치기

하지만, 해당 노드에 ssh 로 접근해서 docker 등으로 직접 접근은 할 수 있다!

node ssh 는 애초에 security group으로 막혀있지만 열었고..
node ssh 접근 후
pod 들 중 배포 권한이 있는 유일무이하게 권한이 많은 pod container 에 docker exec로 들어갔고
docker 에 물려있는 권한으로 수정했네요

해당 파드에 들어간 다음에, 해결은 어떻게?

https://stackoverflow.com/questions/62940549/kubernetes-user-cannot-list-pods-in-namespace

위의 내용을 이번 사례에 따라 정리해보면 이렇다.
해당 네임스페이스(default)에 롤바인딩을 하자.
1. 롤(role)을 만들고

kubectl create role XXX --verb=get,list,watch \
 --resource=pods,pods/status

 

2. 만든 롤을 추가로 바인딩해주자

kubectl create rolebinding XXX-binding --role=XXX --user=XXX \
 --serviceaccount=default:default

3. 해당 롤로 파드 접근이 가능한지 보자.

kubectl auth can-i get pods --as XXX

yes 라고 나오면, 문제 해결