Compartir a través de

Uso del inicio de sesión único de Active Directory para una conexión segura con el servidor de API de Kubernetes en AKS habilitado por Azure Arc

  • Artículo

Se aplica a: AKS en Azure Stack HCI 22H2, AKS en Windows Server

Puede crear una conexión segura al servidor de API de Kubernetes en AKS habilitado mediante Arc mediante credenciales de inicio de sesión único (SSO) de Active Directory (AD).

Introducción a AD en AKS habilitado por Arc

Sin la autenticación de Active Directory, debe confiar en un archivo kubeconfig basado en certificados al conectarse al servidor de API mediante el kubectl comando . El archivo kubeconfig contiene secretos, como claves privadas y certificados, que se deben distribuir con cuidado, y que pueden significar un riesgo de seguridad importante.

Como alternativa al uso de kubeconfig basado en certificados, puede usar credenciales de SSO de AD como una manera segura de conectarse al servidor de API. La integración de AD con AKS Arc permite a los usuarios de una máquina unida a un dominio de Windows conectarse al servidor de API mediante kubectl sus credenciales de SSO. Esto elimina la necesidad de administrar y distribuir archivos kubeconfig basados en certificados que contienen claves privadas.

La integración de AD usa kubeconfig de AD, que es diferente de los archivos kubeconfig basados en certificados y no contiene ningún secreto. No obstante, el archivo kubeconfig basado en certificados se puede usar con fines de copia de seguridad, como solución de problemas si hay problemas con la conexión mediante credenciales de Active Directory.

Otra ventaja de seguridad con la integración de AD es que los usuarios y los grupos se almacenan como identificadores de seguridad (SID). A diferencia de los nombres de grupo, los SID son inmutables y únicos y, por tanto, no presentan conflictos de nomenclatura.

Nota:

La conectividad de AD SSO solo se admite para clústeres de cargas de trabajo.

Nota:

No se admite el uso de grupos de AD anidados (creación de un grupo de AD dentro de otro grupo de AD).

Este artículo le guía por los pasos para configurar Active Directory como proveedor de identidades y para habilitar el inicio de sesión único a través kubectlde :

Antes de empezar

Antes de iniciar el proceso de configuración de las credenciales de inicio de sesión único de Active Directory, debe asegurarse de que dispone de los siguientes elementos:

  • Está instalado el módulo Aks-Hci de PowerShell más reciente. Si tiene que instalarlo, consulte Descarga e instalación del módulo AksHci de PowerShell.

  • El host de AKS está instalado y configurado. Si tiene que instalar el host, siga los pasos para configurar la implementación.

  • El archivo keytab está disponible para su uso. Si no está disponible, siga los pasos para crear la cuenta de AD del servidor de API y el archivo keytab.

    Nota:

    Tiene que generar el archivo keytab para un nombre de entidad de seguridad de servicio (SPN) específico, y este SPN debe corresponder a la cuenta de AD del servidor de API del clúster de cargas de trabajo. También tiene que asegurarse de que se usa el mismo SPN a lo largo del proceso de autenticación de AD. El archivo keytab se debe llamar current.keytab.

  • Hay una cuenta de AD de servidor de API disponible para cada clúster de cargas de trabajo de AKS.

  • La máquina cliente debe ser una máquina unida a un dominio de Windows.

Creación de la autenticación de AD con el archivo keytab

Paso 1: Creación del clúster de cargas de trabajo y habilitación de la autenticación de AD

Antes de instalar la autenticación de AD, primero debe crear un clúster de cargas de trabajo de AKS y habilitar el complemento de autenticación de AD en el clúster. Si no habilita la autenticación de AD al crear el nuevo clúster, no podrá habilitarla más adelante.

Abra PowerShell como administrador y ejecute lo siguiente mediante el -enableADAuth parámetro del New-AksHciCluster comando :

New-AksHciCluster -name mynewcluster1 -enableADAuth

Para cada clúster de cargas de trabajo, asegúrese de que hay una cuenta de AD de servidor de API disponible.

Para obtener información sobre cómo crear el clúster de cargas de trabajo, consulte Creación de clústeres de Kubernetes mediante Windows PowerShell.

Paso 2: Instalación de la autenticación de AD

Antes de poder instalar la autenticación de AD, se tiene que instalar el clúster de cargas de trabajo y habilitar la autenticación de AD en el clúster. Para instalar la autenticación de AD, use una de las siguientes opciones.

Opción 1

Para un clúster de Azure Stack HCI o Windows Server unido a un dominio, abra PowerShell como administrador y ejecute el siguiente comando:

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminUser contoso\bob

Nota:

Para SPN k8s/apiserver@CONTOSO.com, use el formato SPN k8s/apiserver@<realm name>. En el primer intento, especifique <realm name> en mayúsculas. Sin embargo, si tiene problemas con letras mayúsculas, cree el SPN con letras minúsculas. Kerberos distingue entre mayúsculas y minúsculas.

Opción 2

Si el host del clúster no está unido a un dominio, use el nombre de usuario de administrador o el nombre de grupo en formato SID, como se muestra en el ejemplo siguiente.

Usuario administrador:

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminUserSID <User SID>

Grupo de administración:

Install-AksHciAdAuth -name mynewcluster1 -keytab .\current.keytab -SPN k8s/apiserver@CONTOSO.COM -adminGroupSID <Group SID>

Para encontrar el identificador de seguridad de la cuenta de usuario, consulte Determinación del identificador de seguridad del usuario o el grupo.

Antes de continuar con los pasos siguientes, anote los siguientes elementos:

  • Asegúrese de que el archivo keytab se llama current.keytab.
  • Reemplace el SPN correspondiente a su entorno.
  • El -adminGroup parámetro crea un enlace de rol correspondiente para el grupo de AD especificado con privilegios de administrador del clúster. Reemplace contoso\bob (como se muestra en la opción 1 anterior) por el grupo de AD o el usuario que corresponda a su entorno.

Paso 3: Prueba del webhook de AD y el archivo keytab

Asegúrese de que el webhook de AD se ejecuta en el servidor de API y el archivo keytab se almacena como un secreto de Kubernetes. Para obtener el archivo kubeconfig basado en certificado para el clúster de cargas de trabajo, siga estos pasos:

  1. Obtenga un archivo kubeconfig basado en certificado mediante el comando siguiente. Use el archivo kubeconfig para conectarse al clúster como host local:

    Get-AksHciCredential -name mynewcluster1

  2. Ejecute kubectl en el servidor al que se ha conectado (con el archivo kubeconfig basado en certificados que creó anteriormente) y, a continuación, compruebe la implementación de webhook de AD para asegurarse de que está en el formato ad-auth-webhook-xxxx:

    kubectl get pods -n=kube-system

  3. Ejecute kubectl para comprobar que el archivo keytab está implementado como un secreto y aparece como un secreto de Kubernetes:

    kubectl get secrets -n=kube-system

Paso 4: Creación del archivo kubeconfig de AD

Una vez que el webhook de AD y el archivo keytab se hayan implementado correctamente, cree el archivo kubeconfig de AD. Una vez creado el archivo, copie el archivo kubeconfig de AD en la máquina cliente y úselo para autenticarse en el servidor de API. A diferencia del archivo kubeconfig basado en certificado, el archivo kubeconfig de AD no es un secreto y se puede copiar con seguridad como texto sin formato.

Abra PowerShell como administrador y ejecute el siguiente comando:

Get-AksHciCredential -name mynewcluster1 -configPath .\AdKubeconfig -adAuth

Paso 5: Copia del archivo kubeconfig y otros archivos en la máquina cliente

Debe copiar los tres archivos siguientes del clúster de cargas de trabajo de AKS en la máquina cliente:

  • Copie el archivo kubeconfig de AD creado en el paso anterior a $env:USERPROFILE.kube\config.

  • Cree la ruta de acceso de carpeta c:\adsso y copie los archivos siguientes del clúster de carga de trabajo de AKS en el equipo cliente:

    • Kubectl.exe en $env:ProgramFiles\AksHci a c:\adsso.
    • Kubectl-adsso.exe en $env:ProgramFiles\AksHci a c:\adsso.

    Nota:

    El archivo adsso.exe se genera en el servidor al ejecutar el Get-AksHciCredential cmdlet .

Paso 6: Conexión al servidor de API desde la máquina cliente

Después de completar los pasos anteriores, use las credenciales de SSO para iniciar sesión en la máquina cliente unida a un dominio de Windows. Abra PowerShell y, a continuación, intente acceder al servidor de API mediante kubectl. Si la operación se completa correctamente, configuró el inicio de sesión único de AD correctamente.

Creación y actualización del enlace de roles del grupo de AD

Como se mencionó en el paso 2, se crea un enlace de roles predeterminado con privilegios de administrador del clúster para el usuario o el grupo que se proporcionó durante la instalación. El enlace de roles de Kubernetes define las directivas de acceso para los grupos de AD. En este paso se describe cómo usar RBAC para crear nuevos enlaces de roles de grupo de AD en Kubernetes y para editar enlaces de roles existentes. Por ejemplo, el administrador del clúster podría querer conceder privilegios adicionales a los usuarios mediante grupos de AD (lo que hace que el proceso sea más eficaz). Para obtener más información sobre RBAC, consulte Uso de la autorización de RBAC.

Al crear u editar otras entradas de RBAC del grupo de AD, el nombre del firmante debe tener el prefijo microsoft:activedirectory:CONTOSO\group name . Tenga en cuenta que los nombres deben contener un nombre de dominio y un prefijo entre comillas dobles.

Estos son dos ejemplos:

Ejemplo 1

apiVersion: rbac.authorization.k8s.io/v1 
kind: ClusterRoleBinding 
metadata: 
  name: ad-user-cluster-admin 
roleRef: 
  apiGroup: rbac.authorization.k8s.io 
  kind: ClusterRole 
  name: cluster-admin 
subjects: 
- apiGroup: rbac.authorization.k8s.io 
  kind: User 
  name: "microsoft:activedirectory:CONTOSO\Bob"

Ejemplo 2

En el ejemplo siguiente se muestra cómo crear un rol personalizado y un enlace de roles para un espacio de nombres con un grupo de AD. En el ejemplo, SREGroup es un grupo preexistente en Contoso Active Directory. Cuando se agregan usuarios al grupo de AD, se les conceden privilegios inmediatamente.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sre-user-full-access
  namespace: sre
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources:
  - jobs
  - cronjobs
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ad-user-cluster-admin
  namespace: sre
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: sre-user-full-access
subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: "microsoft:activedirectory:CONTOSO\SREGroup"

Antes de aplicar el archivo YAML, los nombres de grupo y de usuario siempre deben convertirse en SID mediante el comando :

kubectl-adsso nametosid <rbac.yml>

Del mismo modo, para actualizar un RBAC existente, puede convertir el SID a un nombre de grupo descriptivo antes de realizar los cambios. Para convertir el SID, use el comando:

kubectl-adsso sidtoname <rbac.yml>

Cambio de la contraseña de la cuenta de AD asociada a la cuenta del servidor de API

Cuando se cambia la contraseña de la cuenta de servidor de API, debe desinstalar el complemento de autenticación de AD y volver a instalarlo con el archivo keytab actual y el anterior.

Cada vez que cambie la contraseña, debe cambiar el nombre del archivo keytab actual (current.keytab) a previous.keytab. Luego, asegúrese de que el nombre de la nueva contraseña es current.keytab.

Importante

Los archivos deben tener el nombre current.keytab y previous.keytab respectivamente. Este cambio no afecta a los enlaces de rol existentes.

Desinstalación y reinstalación de la autenticación de AD

Es posible que quiera volver a instalar el inicio de sesión único de AD cuando se cambia la cuenta del servidor de API, cuando se actualiza la contraseña o para solucionar un error.

Para desinstalar la autenticación de AD, abra PowerShell como administrador y ejecute el siguiente comando:

Uninstall-AksHciAdAuth -name mynewcluster1

Para reinstalar la autenticación de AD, abra PowerShell como administrador y ejecute el siguiente comando:

Install-AksHciAdAuth -name mynewcluster1 -keytab <.\current.keytab> -previousKeytab <.\previous.keytab> -SPN <service/principal@CONTOSO.COM> -adminUser CONTOSO\Bob

Nota:

Para evitar tiempo de inactividad si los clientes tienen vales almacenados en caché, el -previousKeytab parámetro solo es necesario cuando se cambia la contraseña.

Creación de la cuenta de AD del servidor de API y el archivo keytab

Dos pasos están implicados en la creación de la cuenta de AD y el archivo keytab. En primer lugar, cree una nueva cuenta o usuario de AD para el servidor de API con el nombre de entidad de seguridad de servicio (SPN) y, en segundo lugar, cree un archivo keytab para la cuenta de AD.

Paso 1: Creación de una nueva cuenta o un nuevo usuario de AD para el servidor de API

Use el comando de PowerShell New-ADUser para crear una nueva cuenta o un nuevo usuario de AD con el SPN. Este es un ejemplo:

New-ADUser -Name apiserver -ServicePrincipalNames k8s/apiserver -AccountPassword (ConvertTo-SecureString "password" -AsPlainText -Force) -KerberosEncryptionType AES128 -Enabled 1

Paso 2: Creación del archivo keytab para la cuenta de AD

Para crear el archivo keytab, use el comando ktpass De Windows.

A continuación se muestra un ejemplo de uso de ktpass:

ktpass /out current.keytab /princ k8s/apiserver@CONTOSO.COM /mapuser contoso\apiserver_acct /crypto all /pass p@$$w0rd /ptype KRB5_NT_PRINCIPAL

Nota:

Si ve el error DsCrackNames devuelto 0x2 en la entrada de nombre, asegúrese de que el parámetro para /mapuser está en forma mapuser DOMAIN\user, donde DOMAIN es la salida de echo %userdomain%.

Determinación del identificador de seguridad del usuario o el grupo

Use una de las dos opciones siguientes para buscar el SID de su cuenta u otras cuentas:

  • Para buscar el SID asociado a su cuenta, en un símbolo del sistema del directorio principal, escriba el siguiente comando:

    whoami /user

  • Para buscar el SID asociado a otra cuenta, abra PowerShell como administrador y ejecute el siguiente comando:

    (New-Object System.Security.Principal.NTAccount(<CONTOSO\Bob>)).Translate([System.Security.Principal.SecurityIdentifier]).value

Solución de problemas de certificados

El webhook y el servidor de API usan certificados para validar mutuamente la conexión TLS. Este certificado expira en 500 días. Para comprobar que el certificado ha expirado, vea los registros de un contenedor ad-auth-webhook:

kubectl logs ad-auth-webhook-xxx

Si ve errores de validación de certificados, complete los pasos para desinstalar y reinstalar el webhook y obtener nuevos certificados.

Procedimientos recomendados y limpieza

  • Use una cuenta única para cada clúster.
  • No reutilice la contraseña de la cuenta del servidor de API de un clúster en otro.
  • Elimine la copia local del archivo keytab en cuanto cree el clúster y compruebe que las credenciales de inicio de sesión único funcionan.
  • Elimine el usuario de Active Directory que se creó para el servidor de API. Para más información, consulte Remove-ADUser.

Pasos siguientes

En esta guía de procedimientos, ha aprendido a configurar la autenticación de AD para conectarse de forma segura al servidor de API con las credenciales de SSO. A continuación, puede realizar: