Use Kubernetes RBAC com Microsoft Entra ID no AKS

O Serviço Kubernetes do Azure (AKS) pode ser configurado para usar o Microsoft Entra ID para autenticação do usuário. Nessa configuração, você entra em um cluster AKS usando um token de autenticação do Microsoft Entra. Uma vez autenticado, pode usar o controlo de acesso baseado em papéis (RBAC) incorporado do Kubernetes para gerir o acesso a namespaces e recursos de cluster com base na identidade do utilizador ou na pertença ao grupo.

Este artigo mostra-lhe como:

  • Controle o acesso usando o Kubernetes RBAC em um cluster AKS com base na associação ao grupo Microsoft Entra.

  • Crie grupos e usuários de exemplo no Microsoft Entra ID.

  • Criar Funções e RoleBindings num cluster AKS, concedendo as permissões apropriadas para criar e visualizar recursos.

Pré-requisitos

  • Você tem um cluster AKS existente com a integração do Microsoft Entra habilitada. Se precisar de um cluster AKS com esta configuração, consulte Integrar o Microsoft Entra ID com o AKS.

  • O RBAC do Kubernetes é ativado por padrão durante a criação do cluster AKS. Para atualizar um cluster existente com integração Microsoft Entra e Kubernetes RBAC, consulte Ativar integração Microsoft Entra no seu cluster AKS existente.

  • Certifique-se de que a CLI do Azure versão 2.0.61 ou posterior está instalada e configurada. Para localizar a versão, execute az --version. Para instalar ou atualizar, consulte Install CLI do Azure.

Use o portal do Azure ou a CLI do Azure para verificar se a integração do Microsoft Entra com o RBAC do Kubernetes está habilitada.

Para verificar usando o portal do Azure:

  1. Inicie sessão no portal Azure e navegue até ao seu recurso do cluster AKS.
  2. No menu de serviço, em Configurações, selecione Configuração de segurança.
  3. Na seção Autenticação e Autorização, verifique se a opção Autenticação do Microsoft Entra com RBAC do Kubernetes está selecionada.

Se planeia usar o Terraform para configurar o RBAC do Kubernetes neste artigo, também precisa de:

  • Terraform versão 1.6.0 ou posterior instalada.
  • Kubectl instalado e configurado para se ligar ao teu cluster AKS. kubectlé instalado automaticamente quando executa az aks install-cli ou como parte do Azure Cloud Shell.
  • Permissão para criar atribuições de funções no Azure no âmbito do seu cluster AKS, e permissão para gerir os recursos Kubernetes no cluster.
  • Dois grupos existentes do Microsoft Entra e, opcionalmente, dois utilizadores de teste existentes do Microsoft Entra para validar o acesso. Se ainda não tem estes recursos, complete o Criar grupos no Microsoft Entra ID e Criar utilizadores no Microsoft Entra ID antes de continuar. No entanto, ignore o comando az role assignment create nessa secção, pois a configuração do Terraform neste artigo cria as atribuições de funções por si.

Note

Se ainda não tiver um cluster AKS com integração com o Microsoft Entra e RBAC do Kubernetes ativado para realizar testes, o exemplo de Terraform deste artigo inclui uma configuração prequisite que cria esse cluster por si. Para mais informações, consulte Implementar o cluster AKS pré-requisito com o Terraform.

Crie grupos no Microsoft Entra ID

Esta secção ensina-te a criar dois papéis de utilizador para mostrar como o RBAC do Kubernetes e o ID Microsoft Entra controlam os recursos do cluster de acesso. Os seguintes dois papéis exemplos são:

  • Desenvolvedor de aplicativos

    • Um usuário chamado aksdev que faz parte do grupo appdev .

  • Site Reliability Engineer (SRE)

    • Um usuário chamado akssre que faz parte do grupo opssre .

Em ambientes de produção, você pode usar usuários e grupos existentes em um locatário do Microsoft Entra.

  1. Primeiro, obtenha o ID do recurso do seu cluster AKS usando o az aks show comando. Em seguida, atribua o ID do recurso a uma variável chamada AKS_ID para que ela possa ser referenciada em outros comandos.

    AKS_ID=$(az aks show \
    --resource-group myResourceGroup \
    --name myAKSCluster \
    --query id -o tsv)

  2. Crie o primeiro grupo de exemplo no Microsoft Entra ID para os desenvolvedores de aplicativos usando o az ad group create comando. O exemplo a seguir cria um grupo chamado appdev:

    APPDEV_ID=$(az ad group create --display-name appdev --mail-nickname appdev --query id -o tsv)

  3. Crie uma atribuição de função do Azure para o grupo appdev usando o az role assignment create comando. Essa atribuição permite que qualquer membro do grupo use kubectl para interagir com um cluster AKS, concedendo-lhes a Função de Usuário do Cluster de Serviço Kubernetes do Azure.

    az role assignment create \
  --assignee $APPDEV_ID \
  --role "Azure Kubernetes Service Cluster User Role" \
  --scope $AKS_ID

    Importante

    O nome da função que você especificar deve corresponder exatamente ao nome da definição da função do Azure, incluindo capitalização e espaçamento.

    Tip

    Se você receber um erro como Principal 35bfec9328bd4d8d9b54dea6dac57b82 doesn't exist in the directory a5443dcd-cd0e-494d-a387-3039b419f0d5., aguarde alguns segundos para que a ID do objeto de grupo do Microsoft Entra se propague pelo diretório e tente o az role assignment create comando novamente.

    Ignora este comando. A configuração do Terraform no Deploy Kubernetes RBAC com Terraform cria esta atribuição de função para si.

Criar usuários no Microsoft Entra ID

Depois de criar os exemplos de grupos Microsoft Entra ID para programadores de aplicações e SREs, o passo seguinte é criar duas contas de utilizador correspondentes. Estes utilizadores são usados para iniciar sessão no cluster AKS e validar a integração Kubernetes RBAC descrita mais adiante neste artigo.

Antes de começar, deve definir o nome principal de utilizador (UPN) e a palavra-passe para os programadores da aplicação. O UPN deve incluir o nome de domínio verificado do seu inquilino. Por exemplo, um utilizador programador de aplicações, aksdev@contoso.com. Para identificar ou definir os nomes de domínio verificados no seu locatário, consulte Gerir nomes de domínio personalizados no ID do Microsoft Entra.

O comando a seguir solicita o UPN e o define como AAD_DEV_UPN para que possa ser usado em um comando posterior:

echo "Please enter the UPN for application developers: " && read AAD_DEV_UPN

O comando a seguir solicita a senha e a define como AAD_DEV_PW para uso em um comando posterior:

echo "Please enter the secure password for application developers: " && read AAD_DEV_PW

Criar contas de utilizador

  1. Crie a primeira conta de usuário no Microsoft Entra ID usando o az ad user create comando. O exemplo seguinte cria um utilizador com o nome de exibição AKS Dev, o UPN e a palavra-passe segura usando os valores em AAD_DEV_UPN e AAD_DEV_PW:

    AKSDEV_ID=$(az ad user create \
  --display-name "AKS Dev" \
  --user-principal-name $AAD_DEV_UPN \
  --password $AAD_DEV_PW \
  --query id -o tsv)

  2. Adicione o utilizador ao grupo de appdev criado na secção anterior usando o az ad group member add comando:

    az ad group member add --group appdev --member-id $AKSDEV_ID

Criar recursos de clusters AKS

Temos nossos grupos do Microsoft Entra, usuários e atribuições de função do Azure criados. Agora, você configura o cluster AKS para permitir que esses diferentes grupos acessem recursos específicos.

  1. Obtenha as credenciais de administrador do cluster usando o az aks get-credentials comando. Numa das secções seguintes, obterás as credenciais de cluster de utilizador regular para ver o fluxo de autenticação do Microsoft Entra em ação.

    az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin

  2. Crie um namespace no cluster AKS usando o kubectl create namespace comando. O exemplo a seguir cria um nome de namespace dev:

    kubectl create namespace dev

    Note

    No Kubernetes, as Funções definem as permissões a serem concedidas e as RoleBindings as aplicam aos usuários ou grupos desejados. Essas atribuições podem ser aplicadas a um determinado namespace ou em todo o cluster. Para obter mais informações, consulte Usar a autorização RBAC do Kubernetes.

    Se o utilizador para o qual conceder a vinculação RBAC do Kubernetes estiver no mesmo inquilino Microsoft Entra, atribua permissões com base no UPN. Se o utilizador estiver num inquilino diferente do Microsoft Entra, consulte e utilize a propriedade objectId .

  3. Crie uma Função para o namespace dev , que concede permissões totais ao namespace. Em ambientes de produção, você pode especificar permissões mais granulares para diferentes usuários ou grupos. Crie um arquivo chamado role-dev-namespace.yaml e cole o seguinte manifesto YAML:

    kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: dev-user-full-access
  namespace: dev
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources:
  - jobs
  - cronjobs
  verbs: ["*"]

  4. Crie a função usando o kubectl apply comando e especifique o nome do arquivo do seu manifesto YAML.

    kubectl apply -f role-dev-namespace.yaml

  5. Obtenha o ID do recurso para o grupo appdev usando o az ad group show comando. Este grupo é definido como o "objeto" de um RoleBinding na próxima etapa.

    az ad group show --group appdev --query id -o tsv

  6. Crie um RoleBinding para o grupo appdev usar o Role criado anteriormente para acesso ao namespace. Crie um arquivo chamado rolebinding-dev-namespace.yaml e cole o seguinte manifesto YAML. Na última linha, substitua groupObjectId pela saída de ID do objeto de grupo do comando anterior.

    kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: dev-user-access
  namespace: dev
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: dev-user-full-access
subjects:
- kind: Group
  # Replace the placeholder below with the group's objectId (GUID)
  name: groupObjectId

    Tip

    Se quiser criar o RoleBinding para um único utilizador, especifique type: User e substitua groupObjectId pelo UPN na amostra anterior.

  7. Crie o RoleBinding usando o kubectl apply comando e especifique o nome do arquivo do seu manifesto YAML:

    kubectl apply -f rolebinding-dev-namespace.yaml

Revise o código do Terraform

Note

O código de exemplo para este artigo está localizado no repositório GitHub do Azure Terraform. Você pode visualizar o arquivo de log que contém os resultados do teste das versões atual e anterior do Terraform.

Veja mais artigos e código de exemplo mostrando como usar o Terraform para gerenciar recursos do Azure.

O exemplo utiliza duas configurações Terraform, cada uma no seu próprio diretório com o seu próprio estado:

  • A configuração prequisite cria um grupo de recursos e um cluster AKS com integração com o Microsoft Entra e RBAC do Kubernetes ativado, que são utilizados pelos testes end-to-end do próprio repositório para validar a configuração do cenário num cluster real. Se já tiver um cluster AKS que cumpra os pré-requisitos deste artigo, evite esta configuração e use o nome do seu próprio grupo de recursos, nome do cluster e IDs de objetos do grupo Microsoft Entra com a configuração do cenário.
  • A configuração do cenário, na raiz da amostra, atribui o Azure Kubernetes Service Cluster User Role aos grupos appdev e opssre no âmbito do cluster. Também cria os namespaces do Kubernetes dev e sre, com Roles e RoleBindings delimitados ao namespace, que concedem a cada grupo acesso apenas ao respetivo namespace.

O Terraform autentica-se usando o seu contexto de início de sessão na CLI do Azure. Antes de continuar, certifique-se de que tem sessão iniciada usando az login e de que selecionou a subscrição correta usando az account set --subscription <subscription-id>.

Implemente o cluster AKS necessário utilizando o Terraform

Note

Esta fase é opcional. Conclua-o apenas se ainda não tiver, para testar, um cluster do AKS com integração com o Microsoft Entra e o RBAC do Kubernetes ativado, e com o Azure RBAC para Autorização do Kubernetes desativado.

  1. Cria um diretório com nome prequisite e faz dele o teu diretório atual.

  2. Crie um arquivo chamado versions.tf e insira o seguinte código:

    terraform {
  required_version = ">= 1.6.0"

  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.0"
    }
    random = {
      source  = "hashicorp/random"
      version = "~> 3.6"
    }
  }
}

provider "azurerm" {
  features {
    resource_group {
      prevent_deletion_if_contains_resources = false
    }
  }
}

  3. Crie um ficheiro com nome variables.tf e adicione o seguinte código:

    variable "location" {
  type        = string
  default     = "eastus"
  description = "Location of the resources."
}

variable "node_count" {
  type        = number
  default     = 1
  description = "Number of nodes in the default node pool of the AKS cluster."
}

  4. Crie um ficheiro com nome main.tf e adicione o seguinte código:

    data "azurerm_client_config" "current" {}

resource "random_string" "suffix" {
  length  = 6
  special = false
  upper   = false
}

resource "azurerm_resource_group" "rg" {
  location = var.location
  name     = "rg-101-aks-entra-k8s-rbac-${random_string.suffix.result}"
}

resource "azurerm_kubernetes_cluster" "aks" {
  location            = azurerm_resource_group.rg.location
  name                = "aks-101-entra-k8s-rbac-${random_string.suffix.result}"
  resource_group_name = azurerm_resource_group.rg.name
  dns_prefix          = "aks-${random_string.suffix.result}"
  # Kubernetes RBAC is required by the example, Azure RBAC for Kubernetes
  # Authorization must stay disabled.
  role_based_access_control_enabled = true

  default_node_pool {
    name       = "agentpool"
    node_count = var.node_count
    vm_size    = "Standard_D2s_v3"
  }

  identity {
    type = "SystemAssigned"
  }

  azure_active_directory_role_based_access_control {
    azure_rbac_enabled = false
    tenant_id          = data.azurerm_client_config.current.tenant_id
  }
}

  5. Crie um arquivo chamado outputs.tf e insira o seguinte código:

    output "resource_group_name" {
  description = "Name of the resource group that contains the AKS cluster."
  value       = azurerm_resource_group.rg.name
}

output "aks_cluster_name" {
  description = "Name of the AKS cluster with Microsoft Entra integration and Kubernetes RBAC enabled."
  value       = azurerm_kubernetes_cluster.aks.name
}

output "appdev_group_object_id" {
  description = "Object ID of the existing test principal used for developer access."
  value       = data.azurerm_client_config.current.object_id
}

output "opssre_group_object_id" {
  description = "Object ID of the existing test principal used for SRE access."
  value       = azurerm_kubernetes_cluster.aks.identity[0].principal_id
}

  6. Inicialize, formate e valide a configuração.

    terraform init
terraform fmt
terraform validate

  7. Revê e aplica a configuração.

    terraform plan -out main.tfplan
terraform apply main.tfplan

  8. Obter as saídas. Usas estes valores como entrada para a configuração do cenário na secção seguinte.

    terraform output -raw resource_group_name
terraform output -raw aks_cluster_name
terraform output -raw appdev_group_object_id
terraform output -raw opssre_group_object_id

Importante

As saídas appdev_group_object_id e opssre_group_object_id da configuração prequisite são IDs de principais de teste, não grupos reais do Microsoft Entra. Correspondem ao ID do objeto da conta do CLI do Azure com sessão iniciada e ao ID da entidade de segurança da identidade gerida do cluster AKS, e existem apenas para que os testes automatizados do repositório possam validar que a configuração do cenário é aplicada com êxito. Para testar o grupo Microsoft Entra e a experiência do utilizador descrita neste artigo, utilize os IDs de objetos de grupo dos grupos Create no Microsoft Entra ID em vez disso.

Implementar o RBAC do Kubernetes com o Terraform

  1. Cria um novo diretório, separado de prequisite, e faz dele o teu diretório atual. Esta configuração tem o seu próprio estado Terraform e não gere nem depende do estado da prequisite configuração.

  2. Crie um ficheiro com nome main.tf e adicione o seguinte código:

    terraform {
  required_version = ">= 1.6.0"

  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 4.0"
    }
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "~> 2.30"
    }
  }
}

provider "azurerm" {
  features {}
}

variable "resource_group_name" {
  type        = string
  description = "Name of the resource group that contains the existing AKS cluster."
}

variable "aks_cluster_name" {
  type        = string
  description = "Name of the existing AKS cluster with Microsoft Entra integration and Kubernetes RBAC enabled."
}

variable "appdev_group_object_id" {
  type        = string
  description = "Object ID of an existing Microsoft Entra group used for developer access to the dev namespace."
}

variable "opssre_group_object_id" {
  type        = string
  description = "Object ID of an existing Microsoft Entra group used for SRE access to the sre namespace."
}

data "azurerm_kubernetes_cluster" "aks" {
  name                = var.aks_cluster_name
  resource_group_name = var.resource_group_name
}

provider "kubernetes" {
  host                   = data.azurerm_kubernetes_cluster.aks.kube_admin_config[0].host
  client_certificate     = base64decode(data.azurerm_kubernetes_cluster.aks.kube_admin_config[0].client_certificate)
  client_key             = base64decode(data.azurerm_kubernetes_cluster.aks.kube_admin_config[0].client_key)
  cluster_ca_certificate = base64decode(data.azurerm_kubernetes_cluster.aks.kube_admin_config[0].cluster_ca_certificate)
}

resource "azurerm_role_assignment" "appdev_cluster_user" {
  scope                = data.azurerm_kubernetes_cluster.aks.id
  role_definition_name = "Azure Kubernetes Service Cluster User Role"
  principal_id         = var.appdev_group_object_id
}

resource "azurerm_role_assignment" "opssre_cluster_user" {
  scope                = data.azurerm_kubernetes_cluster.aks.id
  role_definition_name = "Azure Kubernetes Service Cluster User Role"
  principal_id         = var.opssre_group_object_id
}

resource "kubernetes_namespace" "dev" {
  metadata {
    name = "dev"
  }
}

resource "kubernetes_namespace" "sre" {
  metadata {
    name = "sre"
  }
}

resource "kubernetes_role" "dev_full_access" {
  metadata {
    name      = "dev-user-full-access"
    namespace = kubernetes_namespace.dev.metadata[0].name
  }

  rule {
    api_groups = ["", "extensions", "apps"]
    resources  = ["*"]
    verbs      = ["*"]
  }

  rule {
    api_groups = ["batch"]
    resources  = ["jobs", "cronjobs"]
    verbs      = ["*"]
  }
}

resource "kubernetes_role" "sre_full_access" {
  metadata {
    name      = "sre-user-full-access"
    namespace = kubernetes_namespace.sre.metadata[0].name
  }

  rule {
    api_groups = ["", "extensions", "apps"]
    resources  = ["*"]
    verbs      = ["*"]
  }

  rule {
    api_groups = ["batch"]
    resources  = ["jobs", "cronjobs"]
    verbs      = ["*"]
  }
}

resource "kubernetes_role_binding" "dev_user_access" {
  metadata {
    name      = "dev-user-access"
    namespace = kubernetes_namespace.dev.metadata[0].name
  }

  role_ref {
    api_group = "rbac.authorization.k8s.io"
    kind      = "Role"
    name      = kubernetes_role.dev_full_access.metadata[0].name
  }

  subject {
    kind      = "Group"
    name      = var.appdev_group_object_id
    api_group = "rbac.authorization.k8s.io"
  }
}

resource "kubernetes_role_binding" "sre_user_access" {
  metadata {
    name      = "sre-user-access"
    namespace = kubernetes_namespace.sre.metadata[0].name
  }

  role_ref {
    api_group = "rbac.authorization.k8s.io"
    kind      = "Role"
    name      = kubernetes_role.sre_full_access.metadata[0].name
  }

  subject {
    kind      = "Group"
    name      = var.opssre_group_object_id
    api_group = "rbac.authorization.k8s.io"
  }
}

  3. Cria um ficheiro com nome terraform.tfvars e fornece o nome do grupo de recursos e do cluster do AKS que queres configurar, bem como os IDs dos objetos dos grupos de appdev e opssre .

    resource_group_name    = "<resource-group-name>"
aks_cluster_name       = "<aks-cluster-name>"
appdev_group_object_id = "<appdev-group-object-id>"
opssre_group_object_id = "<opssre-group-object-id>"

  4. Inicialize, formate e valide a configuração.

    terraform init
terraform fmt
terraform validate

  5. Revê e aplica a configuração.

    terraform plan -out main.tfplan
terraform apply main.tfplan

    A configuração cria as atribuições de papéis do Azure para ambos os grupos, os namespaces Kubernetes dev e sre, e os Roles e RoleBindings com âmbito de namespace, que concedem ao grupo appdev acesso ao dev e ao grupo opssre acesso ao sre.

Verificar o acesso ao espaço de nomes

  1. Obtenha as credenciais de administrador do cluster usando o az aks get-credentials comando.

    az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin

  2. Verifique se ambos os namespaces existem usando o kubectl get namespaces comando.

    kubectl get namespaces

    A saída mostra os namespaces dev e sre , juntamente com os namespaces padrão criados para o cluster.

Para testar se os grupos appdev e opssre só conseguem aceder ao seu espaço de nomes atribuído, continue a aceder aos recursos do cluster AKS com identidades Microsoft Entra.

Limpeza dos recursos do Terraform

Importante

Destrói a configuração do cenário antes da prequisite configuração. O fornecedor Kubernetes da configuração do cenário precisa que o cluster AKS continue a existir para que o Terraform possa remover os namespaces, Roles e RoleBindings que criou.

  1. No diretório de configuração do cenário, remova as atribuições de funções do Azure, os espaços de nomes, as Funções e as Associações de Funções que este criou.

    terraform destroy

  2. Se implementaste o prequisite cluster AKS apenas para testar este exemplo e já não precisares dele, remove-o do prequisite diretório depois de a configuração do cenário terminar de destruir os seus recursos.

    terraform destroy

Aceda aos recursos do cluster AKS com identidades Microsoft Entra

Agora, teste se as permissões esperadas funcionam quando você cria e gerencia recursos em um cluster AKS. Nesses exemplos, você agenda e exibe pods no namespace atribuído pelo usuário e tenta agendar e exibir pods fora do namespace atribuído.

  1. Redefina o contexto kubeconfig usando o az aks get-credentials comando. Em uma seção anterior, você define o contexto usando as credenciais de administrador do cluster. O usuário administrador ignora os prompts de entrada do Microsoft Entra. Sem o parâmetro --admin, é aplicado o contexto de usuário que requer que todas as solicitações sejam autenticadas usando o Microsoft Entra ID.

    az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing

  2. Agende um pod NGINX básico usando o kubectl run comando no namespace dev :

    kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev

  3. Introduza as credenciais da conta do grupo de appdev (introduza as suas próprias credenciais) no prompt de iniciação de sessão. Depois que você entrar com êxito, o token da conta será armazenado em cache para comandos futuros kubectl . O NGINX é agendado com sucesso, conforme mostrado no seguinte exemplo de saída:

    $ kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev

To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code B24ZD6FP8 to authenticate.

pod/nginx-dev created

  4. Utilize o comando kubectl get pods para visualizar os pods no namespace dev:

    kubectl get pods --namespace dev

  5. Verifique se o status do pod NGINX está em execução. A saída se parece com a seguinte saída:

    $ kubectl get pods --namespace dev

NAME        READY   STATUS    RESTARTS   AGE
nginx-dev   1/1     Running   0          4m

Teste o acesso SRE aos recursos do cluster AKS

Para confirmar que a nossa adesão ao grupo Microsoft Entra e o RBAC Kubernetes funcionam corretamente entre diferentes utilizadores e grupos, experimente os comandos anteriores quando estiver iniciado como utilizador akssre .

  1. Redefina o contexto kubeconfig usando o az aks get-credentials comando que limpa o token de autenticação armazenado anteriormente em cache para o utilizador aksdev.

    az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing

  2. Agendar e visualizar pods no namespace SRE atribuído. Quando solicitado, inicie sessão com as credenciais da conta do grupo opssre (introduza as suas próprias credenciais).

    kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre
kubectl get pods --namespace sre

    Como mostrado na saída de exemplo a seguir, você pode criar e visualizar com êxito os pods:

    $ kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre

  3. Para entrar, use um browser para abrir a página https://microsoft.com/devicelogin e insira o código BM4RHP3FD para autenticar.

    pod/nginx-sre created

$ kubectl get pods --namespace sre

NAME        READY   STATUS    RESTARTS   AGE
nginx-sre   1/1     Running   0

  4. Tente exibir ou agendar pods fora do namespace SRE atribuído.

    kubectl get pods --all-namespaces
kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev

    Esses kubectl comandos falham, conforme mostrado na saída de exemplo a seguir. A associação de grupo do utilizador e a Função e os Vínculos de Funções do Kubernetes não concedem permissões para criar ou gerir recursos noutros namespaces.

    $ kubectl get pods --all-namespaces
Error from server (Forbidden): pods is forbidden: User "akssre@contoso.com" cannot list pods at the cluster scope

$ kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
Error from server (Forbidden): pods is forbidden: User "akssre@contoso.com" cannot create pods in the namespace "dev"

Criar e exibir recursos de cluster fora do namespace atribuído

Para ver pods fora do namespace dev. Use o kubectl get pods comando usando --all-namespaces:

kubectl get pods --all-namespaces

A associação ao grupo do usuário não tem uma Função Kubernetes que permita essa ação, conforme mostrado na saída de exemplo a seguir:

Error from server (Forbidden): pods is forbidden: User "aksdev@contoso.com" cannot list resource "pods" in API group "" at the cluster scope

Da mesma forma, agende um pod num namespace diferente, como o namespace SRE. A associação de grupo do usuário não se alinha com uma Função do Kubernetes e RoleBinding para conceder essas permissões, conforme mostrado na saída de exemplo a seguir:

$ kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace sre

Error from server (Forbidden): pods is forbidden: User "akssre@contoso.com" cannot create resource "pods" in API group "" in the namespace "sre"

Limpar os recursos do cluster

Para limpar todos os recursos, execute os seguintes comandos.

Obtenha o contexto de kubeconfig de administrador e elimine os namespaces dev e sre. Esta ação também elimina os pods, Roles e RoleBindings.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin

kubectl delete namespace dev
kubectl delete namespace sre

Se usou o Terraform para criar os espaços de nomes dev e sre, os Roles e os RoleBindings, consulte Limpar recursos do Terraform em vez de executar kubectl delete namespace.

Elimine as contas de utilizador do Microsoft Entra ID para aksdev e akssre.

az ad user delete --upn-or-object-id $AKSDEV_ID
az ad user delete --upn-or-object-id $AKSSRE_ID

Elimina os grupos de Microsoft Entra ID para appdev e opssre. Esta ação também elimina quaisquer atribuições de funções no Azure restantes.

az ad group delete --group appdev
az ad group delete --group opssre

Passos seguintes

  • Última atualização a