궁금한게 많은 개발자 노트

Azure의 Resource 권한 관리는 다른 CSP와 같이 Role기반으로 이루어지며 특정 리소스에 대한 접근은 해당 Identity에 Role이 부여되었는지 아닌지에 따라 결정됩니다.아래 그림과 같이 각 리소스에 대한 Action을 선택하여 Action들의 집합인 Role을 생성할 수 있고, Service Principal에 필요한 Role을 부여하여 각 Identity에 서비스 주체(Service Principal)를 부여하는 방식으로 각 Identity가 접근 가능한 리소스에 대한 제어(RBAC)를 관리할 수 있습니다.  Security Principal에는 User, Group, Service Principal, Managed Identity가 있으며 User는 Azure의 사용자이고, 여러 사..

Azure구독은 단일 Entra 디렉터리와 연결되어 있다는 점을 기억해야 합니다. 디렉터리의 사용자, 그룹 및 애플리케이션은 Azure 구독에서 리소스를 관리할 수 있습니다. 구독은 SSO 및 액세스 관리를 위해 Entra ID를 사용하며, Entra Connect를 통해 온프레미스 AD를 클라우드로 확장할 수도 있습니다. 온프레미스 AD 계정을 사용하지 않도록 설정함으로써 Entra ID와 연결된 모든 Azure 구독에 대한 액세스 권한이 자동으로 생성됩니다. Azure RBAC은 Azure에서 리소스에 대한 액세스를 세밀하게 관리하는 ARM기반의 권한 부여 시스템입니다. RBAC을 사용하면 사용자가 작업을 수행하는 데 필요한 정확한 액세스 권한을 부여할 수 있습니다. (최소 권한) 역할 할당의 범위는..

AWS에서 제공하는 EKS(Elastic Kubernetes Service)를 사용하다 보면, IAM User권한을 통해 EKS를 생성하고 생성한 User는 클러스터를 구성할 수 있는 system:master권한을 가져, EKS에 접근하거나 EKS내에서 생성된 k8s resource들에 대한 접근 권한이 생성됩니다. 물론, terraform이나 ansible등의 IaC를 사용하여 CLI를 통해 EKS를 구축하였더라도 kube config를 업데이트하여 IAM Role, User, Account등을 지정할 수 있습니다. AWS에서는 AWS서비스에 접근하기 위한 사용자 IAM정보를 ~/.aws/config에 저장해둔다면, EKS에서는 EKS에 접근하기 위한 토큰을 발급하여 사용하도록 하는 정보를 ~/.kub..

Kubernetes RBAC(Role-Based Access Control)은 사용자 및 서비스 계정이 Kubernetes 클러스터의 리소스에 대한 액세스를 제어할 수 있도록 하는 메커니즘을 제공합니다. RBAC에서 Role은 리소스와 연결된 일련의 작업을 나타내는 정책의 집합입니다. Role은 API 그룹, 리소스 및 작업(동사)에 대한 세 가지 주요 속성을 정의합니다. API 그룹은 작업이 수행되는 리소스 유형을 식별하고, 리소스는 액세스 권한이 할당된 대상을 나타내며, 작업은 리소스에 수행될 수 있는 작업(예: create, delete, get, update 등)을 정의합니다. Role은 다음과 같은 필드를 포함합니다. kind: Role apiVersion: Role의 API 버전 metadat..