W ostatnim czasie przeprowadziłem aktualizację repozytorium k8s-ingress-auth, w którym przygotowałem kod do uruchomienia dodatkowego komponentu OAuth2 proxy służącego do uwierzytelniania i autoryzacji użytkowników. Główne zmiany dotyczą integracji z Microsoft Entra ID (dawniej Azure Active Directory):

  1. Dodano wsparcie dla uwierzytelniania przez Microsoft Entra ID
  2. Zaktualizowano konfigurację OAuth proxy do najnowszej wersji
  3. Dodano obsługę grup w Entra ID

Konfiguracja OAuth proxy Link to heading

Najważniejsze elementy konfiguracji OAuth proxy dla Entra ID:

args:
  - --provider=oidc
  - --scope=openid
  - --email-domain=*
  - --oidc-issuer-url=https://login.microsoftonline.com/<tenant-id>/v2.0

Pozostałe ustawienia są podobne (lub identyczne) do tych, jakie wcześniej przygotowałem dla GitHub.

Integracja z Kubernetes Link to heading

Aby zabezpieczyć aplikację w Kubernetes, należy dodać odpowiednie adnotacje w Ingress:

annotations:
  nginx.ingress.kubernetes.io/auth-url: "https://$host/oauth2/auth"
  nginx.ingress.kubernetes.io/auth-signin: "https://$host/oauth2/start?rd=$escaped_request_uri"

Problemy i rozwiązania Link to heading

W trakcie implementacji napotkałem na kilka problemów, dla których znalazłem rozwiązania wymienione niżej:

  1. Problem z rozmiarem buforów ingress kontrolera:
upstream sent too big header while reading response header from upstream

rozwiązany przez dodanie odpowiednich adnotacji:

kind: Ingress
metadata:
  name: oauth2-proxy
  namespace: kube-system
  annotations:
    nginx.ingress.kubernetes.io/proxy-buffer-size: "512k"
  1. Problem z tokenem wygenerowanym tokenem dla innej wersji dostawcy:
solution for problem: Error retrieving session from token in Authorization header: [unable to verify bearer token, failed to verify token: oidc: id token issued by a different provider, expected "https://login.microsoftonline.com/dca11c8d-6718-4495-b1a7-46217af67c69/v2.0" got "https://sts.windows.net/dca11c8d-6718-4495-b1a7-46217af67c69/"]

rozwiązany przez dodatkowe konfigurację dla aplikacji zarejestrowanej w Azure:

api {
  requested_access_token_version = 2
}
  1. Problem z uprawnieniami grup - rozwiązany przez dodanie konfiguracji w aplikacji w Azure:
group_membership_claims = [
  "SecurityGroup"
]

utworzeniem dedykowanych grup w Entra ID:

resource "azuread_group" "oauth2_proxy_users" {
  display_name     = var.oauth2_proxy_group_name
  security_enabled = true
}

data "azuread_user" "my_account" {
  user_principal_name = var.user_principal_name
}

resource "azuread_group_member" "my_account" {
  group_object_id  = azuread_group.oauth2_proxy_users.object_id
  member_object_id = data.azuread_user.my_account.object_id
}

resource "azuread_group_member" "sp" {
  group_object_id  = azuread_group.oauth2_proxy_users.object_id
  member_object_id = azuread_service_principal.sp.object_id
}

i ich użyciem na etapii konfiguracji OAuth2 proxy:

        - name: OAUTH2_PROXY_ALLOWED_GROUPS
          valueFrom:
            secretKeyRef:
              name: oauth2-proxy-allowed-groups
              key: OAUTH2_PROXY_ALLOWED_GROUPS

Podsumowanie Link to heading

Przygotowane zmiany pokazują, że w dosyć prosty sposób można zabezpieczyć aplikacje w Kubernetes wykorzystując OAuth proxy i Microsoft Entra ID. Całość konfiguracji jest dostępna w repozytorium na GitHub, wraz z przykładami i dokumentacją.

Przydatne linki Link to heading