Konfigurowanie zewnętrznych dostawców tożsamości przy użyciu strukturalnego uwierzytelniania AKS (wersja zapoznawcza)

Konfiguracja uwierzytelniania OIDC dla GitHub Actions

1. Upewnij się, że przepływy pracy GitHub Actions mają niezbędne uprawnienia.

2. id-token: write Skonfiguruj uprawnienie w plikach przepływu pracy. Przykład:

   permissions:
     id-token: write
     contents: read
   

3. Skonfiguruj odpowiednie repozytorium i ustawienia organizacji na potrzeby dostępu do tokenów OIDC. Skonfiguruj ustawienia OIDC repozytorium i zasady zabezpieczeń organizacji w zakresie użycia tokenów.

Skonfiguruj uwierzytelnianie Google Identity OAuth 2.0

1. Przejdź do konsoli Google Cloud Console.
2. Utwórz lub wybierz projekt.
3. Utwórz poświadczenia protokołu OAuth 2.0.
4. Zanotuj identyfikator klienta i klucz tajny klienta do późniejszego użycia.

Utwórz konfigurację uwierzytelniania JWT dla GitHub Actions OIDC

• Utwórz plik o nazwie jwt-config.json z następującą konfiguracją:

  {
    "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'"
        }
    ]
  }
  

Utwórz konfigurację uwierzytelniania JWT dla tożsamości Google

• Utwórz plik o nazwie jwt-config.json z następującą konfiguracją:

  {
      "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'"
          }
      ]
  }
  

Konfigurowanie GitHub Actions OIDC na potrzeby uwierzytelniania

1. Utwórz zmienne środowiskowe i ustaw następujące wymagane wpisy tajne w repozytorium GitHub:

   • AKS_SERVER_URL: adres URL interfejsu API serwera klastra AKS.
   • AKS_CA_DATA: dane autoryzacji certyfikatu zakodowane w formacie Base64 dla klastra usługi AKS.

2. Utwórz przepływ pracy, który uzyskuje token OIDC i używa go do uwierzytelniania w klastrze AKS. Poniższy przykładowy przepływ pracy pobiera wszystkie zasobniki uruchomione w klastrze:

   Uwaga / Notatka

   Wartość my-api odbiorcy powinna odpowiadać odbiorcom skonfigurowanym w konfiguracji uwierzytelniacza 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
   

Pobierz informacje o klastrze dla konfiguracji uwierzytelniacza JWT

1. Uzyskaj adres URL serwera API dla klastra, korzystając z polecenia az aks show.

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

2. Pobierz dane urzędu certyfikacji zakodowane w formacie base64 dla klastra az aks get-credentials przy użyciu polecenia .

   # 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}'
   

Konfigurowanie usługi Google Identity OAuth 2.0 na potrzeby uwierzytelniania

Uwierzytelnianie tożsamości Google można skonfigurować przy użyciu kubelogin wtyczki lub bezpośrednio przy użyciu tokenu statycznego.

1. Wyzwól przepływ pracy przez wypchnięcie do gałęzi głównej lub ręczne wyzwolenie go z karty Akcje w repozytorium.

2. Monitoruj wykonywanie przepływu pracy na karcie Akcje, aby sprawdzić, czy uwierzytelnianie działa.

   Oczekiwane rezultaty pierwszej konfiguracji przed ustawieniem 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
   

   Ten błąd wskazuje na pomyślne uwierzytelnienie, ale brak autoryzacji.

• Przetestuj uwierzytelnianie przy użyciu polecenia kubectl get nodes z flagą --user, aby określić kontekst użytkownika utworzony na potrzeby uwierzytelniania Google Identity. Przykład:

  kubectl get nodes --user external-user
  

  Oczekiwane rezultaty pierwszej konfiguracji przed ustawieniem 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
  

  Ten błąd wskazuje na pomyślne uwierzytelnienie, ale brak autoryzacji.

1. Utwórz plik o nazwie rbac-config.yaml w celu skonfigurowania powiązań RBAC dla użytkowników zewnętrznych. Przykład:

   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. Zastosuj konfigurację RBAC, używając polecenia kubectl apply.

   kubectl apply -f rbac-config.yaml
   

1. Utwórz plik o nazwie rbac-config.yaml w celu skonfigurowania powiązań RBAC dla użytkowników zewnętrznych. Przykład:

   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. Zastosuj konfigurację RBAC, używając polecenia kubectl apply.

   kubectl apply -f rbac-config.yaml