Azure Kubernetes Service, 생성 옵션!?
클라우드에서 리소스를 생성할 때, 정말 많은 옵션들을 볼 수 있다. Azure의 Kubernetes, AKS 또한 예외는 아니다.
특정 플랫폼을 도입하기로 하였으면, 생성할 때의 옵션들을 꼼꼼히 보는것은 필수이다.
생성할 때 대충대충 진행하면, 위와 같은 상황을 꽤 자주 겪게된다.
이번 시리즈는 현재 회사에서 진행하는 프로젝트 그 자체이기 때문에, 어떤 선택을 어떤 이유에서 하게 되었는지에 대해서도 공유를 하게 될 것 같다.
모든 플랫폼 도입의 시작점은 Access 부터지!
항상 새로운 플랫폼을 들여올 때 여러가지들이 고려되어져야 한다. 대부분의 플랫폼에 대해 공통적으로 고민하는 부분이 Access에 관련된 부분이다. 해당 플랫폼을 관리하는 입장에서 적절한 Access control을 할 수 없다면 해당 플랫폼 도입 자체를 다시 한번 더 고려해 보는것이 좋다. 웬만해선 Access control이 되지 않는 플랫폼을 찾기가 더 힘든게 현실이다.
운영하는 입장에서 Access 관련하여, 아래의 주요 포인트들이 고려를 하는 편이다.
- 기존에 사용하고 있는 id 서비스와 sso를 할 수 있는가?
- 권한 컨트롤은 가능한가?
AKS에서는 Access 관련하여 뭘 어떻게 제공하고 있을까?
AKS에서는 위의 고려 포인트들에 대해 아래와 같이 제공하고 있다.
AKS에서 고려 포인트들에 대해 현재 제공하고 있는 옵션들
기존에 사용하고 있는 id 서비스와 sso를 할 수 있는가?
먼저 기존 id 서비스와의 sso는, 관리자 입장으로서 웬만해선 있으면 사용하고 싶다. 각각의 플랫폼마다 local account를 두고 사용하는 방향은 관리 포인트가 너무 늘어나기 때문이다.
이 부분준에 있어서, AKS는 Azure AD를 authentication용으로 사용할 수 있게 제공해준다.
권한 컨트롤은 가능한가?
RBAC의 경우, AKS에서는 2가지로 나누어 제공된다.
- Azure RBAC을 Azure AD Auth와 엮어 사용
- Kubernetes RBAC을 Azure AD Auth와 엮어 사용
AKS에서 제공하고 있는 인증 및 RBAC의 종류
위의 포인트들을 알기 쉽게 그림으로 보자면 아래와 같이 제공되고 있는 것을 볼 수 있다.
위 3가지 옵션을 하나하나 조금 자세히 알아보자.
Local accounts with Kubernetes RBAC
이름에서 유추 가능하듯, Kubernetes의 account와 RBAC 둘 다 쓰는 부분이다.
이부분은 Kubernetes이 제공해주는 기본 부분을 사용하기에 따로 설명하지 않겠다.
Azure AD authentication with Kubernetes RBAC
Azure AD를 인증 매체로 사용하고, 권한 부분을 Kubernetes RBAC으로 사용하는 부분이다. 순서는 아래와 같다.
- 생성할 때 Azure AD authentication with Kubernetes RBAC을 선택하고 만든다. (이때 group을 등록하도록 되어 있는데, 해당 그룹안의 멤버들이 AKS로 접속하면 풀권한을 가지고 접속 할 수 있게 된다.)
- Azure Kubernetes Service Cluster User Role 롤 또는 Azure Kubernetes Service Cluster Admin Role 롤을 그룹 또는 유저에게 AKS 리소스 대상으로 부여한다. 1번에서 admin 계정용으로 추가되었더라도, 해당 cluster에 대해 아래의 권한 2개다 없는 경우에는 context를 가져올 수 없다.
- Microsoft.ContainerService/managedClusters/listClusterAdminCredential/action
- Microsoft.ContainerService/managedClusters/listClusterUserCredential/action
위 2개 중 하나라도 권한이 있어야 아래의
az aks get credentials명령어로 context를 가져올 수 있다!!
그리고 문서에는 Azure Kubernetes Service Cluster Admin Role 부분이 나와있지만 실제로 내가 써보니, 이 롤을 부여하고 --admin 옵션값을 줘도 local account가 disable 된 상태에서는 못 쓰는 것 처럼 보였다. 조금 더 자세히 알게되면 업데이트 하겠다.
admin 계정은 1번의 그룹에 추가하고 추가되는 계정은 Azure Kubernetes Service Cluster User Role 롤을 이용하자!!!!
- 위 2번에서 그룹에 추가한 계정 또는 상위 권한을 가진 계정으로 az login 한 후,
az aks get credentials명령어를 통해 AKS context를 받는다.
클러스터에 권한이 없으면 아래와 같이 빨간맛을 보게된다.
- 받은 후, kubectl 명령어를 하면 한번 더 인증을 하는 부분이 나오며, 한번 더 인증한 후에 kubectl을 사용할 수 있다.
4번에서 한번 더 인증하면 아래와 같은 경로에 bearer token이 json 형식으로 저장되며 해당 token을 이용하여 aks에 접근하게 된다. 왜 한번 더 로그인 하지?? 알아보자!
token 정보는 소중하다구!!
왜? 한번 더 로그인 하나요?
처음에 이것저것 테스트를 하며 들었던 의문은 삭제 명령어가 왜 있을까? 보다는 이게 왜 되지? 라는 부분이다.
내가 테스트 한 순서는 아래와 같다.
- az login으로 admin account로 로그인
- kubectl로 로그인 한번 더
- context 삭제 후 az logout
- az login으로 admin이 아닌 Azure Kubernetes Service Cluster User Role 롤만 가진 account로 로그인
kubectl auth can-i "*" "*"- yes ?????? 아직 롤도 안줬는데 왜지??
이것 저것 테스트하며 알아낸 것은, kubelogin의 존재와 az cli는 context 가져오는 부분까지만 이라는 것이다. 실제로 kubectl에 사용될 유저는 2번째 로그인에서 그 유저를 등록하게 되며, kubelogin remove-tokens를 입력하기 전까진 기존에 로그인 해놓은 해당 유저로 계속 kubectl api를 사용하게 된다.
해당 plug-in에 대해 자세히 알고 싶다면 아래 링크를 보자.
https://github.com/Azure/kubelogin
정리해보자면 아래와 같다.
- admin 유저들은 configuration에서 설정한 그룹을 활용하자.
- context를 가져오기 위해선 Azure Kubernetes Service Cluster User Role 롤을 유저에게 부여하고
az aks get credentials를 이용하자. - admin 유저로 적절한 role과 role binding을 부여하고 유저로 사용하자.
- 여러 유저를 사용하기 위해선 context는 그대로 둔 채,
kubelogin remove-tokens명령어를 통해 유저 정보를 지우자. (지우면 kubectl 명령어시 재로그인이 필요하다.)
Azure AD authentication with Azure RBAC
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을 어떻게 사용하는지는 미래의 내가 글을 쓰겠지...
