Настройка внешних поставщиков удостоверений с помощью структурированной проверки подлинности AKS (предварительная версия)

Настройте аутентификацию OIDC для "GitHub Actions"

1. Убедитесь, что рабочие процессы GitHub Actions имеют необходимые разрешения.

2. Настройте id-token: write право доступа в файлах рабочего процесса. Рассмотрим пример.

   permissions:
     id-token: write
     contents: read
   

3. Настройте адекватные параметры репозитория и организации для доступа к маркеру OIDC. Настройте параметры OIDC репозитория и политики безопасности организации для использования токенов.

Настройка проверки подлинности Google Identity OAuth 2.0

1. Перейдите в Google Cloud Console.
2. Создайте или выберите проект.
3. Создайте учетные данные OAuth 2.0.
4. Запишите идентификатор клиента и секрет клиента для последующего использования.

Создание конфигурации проверки подлинности JWT для GitHub Actions OIDC

• Создайте файл с именем jwt-config.json следующей конфигурации:

  {
    "issuer": {
        "url": "https://token.actions.githubusercontent.com",
        "audiences": [
            "my-api"
        ]
    },
    "claimValidationRules": [
        {
            "expression": "has(claims.sub)",
            "message": "must have sub claim"
        }
    ],
    "claimMappings": {
        "username": {
            "expression": "'aks:jwt:github:' + claims.sub"
        }
    },
    "userValidationRules": [
        {
            "expression": "has(user.username)",
            "message": "must have username"
        },
        {
            "expression": "!user.username.startsWith('aks:jwt:github:system')",
            "message": "username must not start with 'aks:jwt:github:system'"
        }
    ]
  }
  

Создание конфигурации проверки подлинности JWT для Google Identity

• Создайте файл с именем jwt-config.json следующей конфигурации:

  {
      "issuer": {
          "url": "https://accounts.google.com",
          "audiences": [
              "your-client-id.apps.googleusercontent.com"
          ]
      },
      "claimValidationRules": [
          {
              "expression": "has(claims.sub)",
              "message": "must have sub claim"
          }
      ],
      "claimMappings": {
          "username": {
              "expression": "'aks:jwt:google:' + claims.sub"
          },
          "groups": {
              "expression": "has(claims.groups) ? claims.groups.split(',').map(g, 'aks:jwt:' + g) : []"
          }
      },
      "userValidationRules": [
          {
              "expression": "has(user.username)",
              "message": "must have username"
          },
          {
              "expression": "!user.username.startsWith('aks:jwt:google:system')",
              "message": "username must not start with 'aks:jwt:google:system'"
          }
      ]
  }
  

Настройка GitHub Actions OIDC для проверки подлинности

1. Создайте переменные окружения и задайте следующие обязательные секреты репозитория в своем репозитории GitHub.

   • AKS_SERVER_URL: URL-адрес сервера API кластера AKS.
   • AKS_CA_DATA: данные центра сертификации в кодировке Base64 для кластера AKS.

2. Создайте рабочий процесс, который получает маркер OIDC и использует его для проверки подлинности в кластере AKS. Следующий пример рабочего процесса получает все модули pod, выполняемые в кластере:

   Замечание

   Значение my-api аудитории должно соответствовать аудитории, настроенной в конфигурации средства проверки подлинности JWT.

   name: AKS Access with GitHub OIDC
   on:
     workflow_dispatch:
     push:
       branches: [main]
   
   permissions:
     id-token: write
     contents: read
   
   jobs:
     aks-access:
       runs-on: ubuntu-latest
       steps:
         - name: Checkout code
           uses: actions/checkout@v4
   
         - name: Install kubectl
           uses: azure/setup-kubectl@v3
           with:
             version: 'latest'
   
         - name: Get GitHub OIDC token
           id: get_token
           run: |
             TOKEN=$(curl -H "Authorization: Bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
               "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=my-api" | \
               jq -r '.value')
             echo "::add-mask::$TOKEN"
             echo "oidc_token=$TOKEN" >> $GITHUB_OUTPUT
   
         - name: Create kubeconfig with OIDC token
           run: |
             cat <<EOF > kubeconfig
             apiVersion: v1
             kind: Config
             clusters:
             - cluster:
                 certificate-authority-data: ${{ secrets.AKS_CA_DATA }}
                 server: ${{ secrets.AKS_SERVER_URL }}
               name: aks-cluster
             contexts:
             - context:
                 cluster: aks-cluster
                 user: github-oidc-user
               name: aks-context
             current-context: aks-context
             users:
             - name: github-oidc-user
               user:
                 token: ${{ steps.get_token.outputs.oidc_token }}
             EOF
   
         - name: List all pods in the cluster
           run: |
             export KUBECONFIG=./kubeconfig
             kubectl get pods --all-namespaces
   

Получение сведений о кластере для конфигурации проверки подлинности JWT

1. Получите URL-адрес сервера API для кластера с помощью az aks show команды.

   az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --query "fqdn" -o tsv | \
     awk '{print "https://" $0 ":443"}'
   

2. Получите данные центра сертификации в кодировке Base64 для кластера с помощью az aks get-credentials команды.

   # Get CA data (base64 encoded)
   az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME --file - --format exec | \
     grep certificate-authority-data | awk '{print $2}'
   

Настройка Google Identity OAuth 2.0 для проверки подлинности

Вы можете настроить проверку подлинности Google Identity с помощью kubelogin плагина или непосредственно с помощью статического токена.

1. Активируйте рабочий процесс, нажав на главную ветвь или вручную активировав его на вкладке "Действия " в репозитории.

2. Отслеживайте выполнение рабочего процесса на вкладке "Действия", чтобы убедиться, что проверка подлинности работает.

   Ожидаемые выходные данные для первой настройки перед настройкой Role-Based Access Control (RBAC):

   Error from server (Forbidden): nodes is forbidden: User "aks:jwt:github:your-sub" cannot list resource "nodes" in API group "" at the cluster scope
   

   Эта ошибка указывает на успешную проверку подлинности, но отсутствие авторизации.

• Проверьте аутентификацию с помощью команды kubectl get nodes и флага --user , чтобы указать контекст пользователя, который вы создали для аутентификации Google Identity. Рассмотрим пример.

  kubectl get nodes --user external-user
  

  Ожидаемые выходные данные для первой настройки перед настройкой Role-Based Access Control (RBAC):

  Error from server (Forbidden): nodes is forbidden: User "aks:jwt:google:your-subject" cannot list resource "nodes" in API group "" at the cluster scope
  

  Эта ошибка указывает на успешную проверку подлинности, но отсутствие авторизации.

1. Создайте файл с именем rbac-config.yaml , чтобы настроить привязки RBAC для внешних пользователей. Рассмотрим пример.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: external-user-role
   rules:
   - apiGroups: [""]
     resources: ["pods", "services", "nodes"]
     verbs: ["get", "list"]
   - apiGroups: ["apps"]
     resources: ["deployments", "replicasets"]
     verbs: ["get", "list"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: external-user-binding
   subjects:
   - kind: User
     # This matches the username expression in claim mappings for GitHub; example of GitHub subject is "repo:<organization-name>/<repository-name>:ref:refs/heads/main"
     name: aks:jwt:github:your-github-sub
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: ClusterRole
     name: external-user-role
     apiGroup: rbac.authorization.k8s.io
   

2. Примените конфигурацию RBAC с помощью kubectl apply команды:

   kubectl apply -f rbac-config.yaml
   

1. Создайте файл с именем rbac-config.yaml , чтобы настроить привязки RBAC для внешних пользователей. Рассмотрим пример.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: external-user-role
   rules:
   - apiGroups: [""]
     resources: ["pods", "services", "nodes"]
     verbs: ["get", "list"]
   - apiGroups: ["apps"]
     resources: ["deployments", "replicasets"]
     verbs: ["get", "list"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: external-user-binding
   subjects:
   - kind: User
     # This matches the username expression in claim mappings for Google
     name: aks:jwt:google:your-subject-claim
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: ClusterRole
     name: external-user-role
     apiGroup: rbac.authorization.k8s.io
   

2. Примените конфигурацию RBAC с помощью kubectl apply команды:

   kubectl apply -f rbac-config.yaml