클라우드에서 리소스를 생성할 때, 정말 많은 옵션들을 볼 수 있다. Azure의 Kubernetes, AKS 또한 예외는 아니다.
특정 플랫폼을 도입하기로 하였으면, 생성할 때의 옵션들을 꼼꼼히 보는것은 필수이다.
생성할 때 대충대충 진행하면, 위와 같은 상황을 꽤 자주 겪게된다.
이번 시리즈는 현재 회사에서 진행하는 프로젝트 그 자체이기 때문에, 어떤 선택을 어떤 이유에서 하게 되었는지에 대해서도 공유를 하게 될 것 같다.
항상 새로운 플랫폼을 들여올 때 여러가지들이 고려되어져야 한다. 대부분의 플랫폼에 대해 공통적으로 고민하는 부분이 Access에 관련된 부분이다. 해당 플랫폼을 관리하는 입장에서 적절한 Access control을 할 수 없다면 해당 플랫폼 도입 자체를 다시 한번 더 고려해 보는것이 좋다. 웬만해선 Access control이 되지 않는 플랫폼을 찾기가 더 힘든게 현실이다.
운영하는 입장에서 Access 관련하여, 아래의 주요 포인트들이 고려를 하는 편이다.
AKS에서는 위의 고려 포인트들에 대해 아래와 같이 제공하고 있다.
먼저 기존 id 서비스와의 sso는, 관리자 입장으로서 웬만해선 있으면 사용하고 싶다. 각각의 플랫폼마다 local account를 두고 사용하는 방향은 관리 포인트가 너무 늘어나기 때문이다.
이 부분준에 있어서, AKS는 Azure AD를 authentication용으로 사용할 수 있게 제공해준다.
RBAC의 경우, AKS에서는 2가지로 나누어 제공된다.
위의 포인트들을 알기 쉽게 그림으로 보자면 아래와 같이 제공되고 있는 것을 볼 수 있다.
위 3가지 옵션을 하나하나 조금 자세히 알아보자.
이름에서 유추 가능하듯, Kubernetes의 account와 RBAC 둘 다 쓰는 부분이다.
이부분은 Kubernetes이 제공해주는 기본 부분을 사용하기에 따로 설명하지 않겠다.
Azure AD를 인증 매체로 사용하고, 권한 부분을 Kubernetes RBAC으로 사용하는 부분이다. 순서는 아래와 같다.
위 2개 중 하나라도 권한이 있어야 아래의
az aks get credentials
명령어로 context를 가져올 수 있다!!
그리고 문서에는 Azure Kubernetes Service Cluster Admin Role 부분이 나와있지만 실제로 내가 써보니, 이 롤을 부여하고 --admin 옵션값을 줘도 local account가 disable 된 상태에서는 못 쓰는 것 처럼 보였다. 조금 더 자세히 알게되면 업데이트 하겠다.
admin 계정은 1번의 그룹에 추가하고 추가되는 계정은 Azure Kubernetes Service Cluster User Role 롤을 이용하자!!!!
az aks get credentials
명령어를 통해 AKS context를 받는다.클러스터에 권한이 없으면 아래와 같이 빨간맛을 보게된다.
4번에서 한번 더 인증하면 아래와 같은 경로에 bearer token이 json 형식으로 저장되며 해당 token을 이용하여 aks에 접근하게 된다. 왜 한번 더 로그인 하지?? 알아보자!
token 정보는 소중하다구!!
처음에 이것저것 테스트를 하며 들었던 의문은 삭제 명령어가 왜 있을까? 보다는 이게 왜 되지? 라는 부분이다.
내가 테스트 한 순서는 아래와 같다.
kubectl auth can-i "*" "*"
이것 저것 테스트하며 알아낸 것은, kubelogin의 존재와 az cli는 context 가져오는 부분까지만 이라는 것이다. 실제로 kubectl에 사용될 유저는 2번째 로그인에서 그 유저를 등록하게 되며, kubelogin remove-tokens
를 입력하기 전까진 기존에 로그인 해놓은 해당 유저로 계속 kubectl api를 사용하게 된다.
해당 plug-in에 대해 자세히 알고 싶다면 아래 링크를 보자.
https://github.com/Azure/kubelogin
정리해보자면 아래와 같다.
az aks get credentials
를 이용하자.kubelogin remove-tokens
명령어를 통해 유저 정보를 지우자. (지우면 kubectl 명령어시 재로그인이 필요하다.)RBAC을 Azure AD에서 전부 관리하는 형식이다. 위의 방식처럼 따로 롤들을 관리할 필요도 없고, 아래의 롤들을 이용해 사용하면 된다.
위의 스크린샷과 같이, kubernetes 관련 built-in 롤들 중, RBAC으로 표기된 롤들을 사용하면 된다. 롤 별 자세한 권한 및 설명은 아래와 같다.
간단하고 명료하지만 kubernetes RBAC을 사용하는 형식보다는 설정할 수 있는 디테일에서 조금 아쉬운 부분이 있다.
조금 더 자세한 설명은 아래 링크를 참고하자!!
https://learn.microsoft.com/en-us/azure/aks/manage-azure-rbac
영문 docs 링크를 계속 올리는 이유는 크리티컬한 오번역에 크게 몇번 당해서ㅠㅠ
AKS에서 제공하는 위 3가지의 방식 중, Azure AD + Kubernetes RBAC 방식을 선택하기로 하였다. local account를 늘려서 관리포인트 만들기는 싫고, kubernetes의 풍부한 rbac을 같이 쓰고 싶었다. 이번 선택으로 얻은 풍부한 rbac을 어떻게 사용하는지는 미래의 내가 글을 쓰겠지...