Implementación de SQL Managed Instance integrado en Active Directory habilitado por Azure Arc
En este artículo se explica cómo implementar Azure SQL Managed Instance habilitado para Azure Arc con autenticación de Active Directory.
Requisitos previos
Antes de comenzar la implementación de SQL Managed Instance, asegúrese de que tiene estos requisitos previos:
- Un dominio de Active Directory.
- Un controlador de datos de Azure Arc implementado
- Un conector de Active Directory implementado con un keytab administrado por el cliente o keytab administrado por el sistema
Requisitos del conector
El conector de Active Directory keytab administrado por el cliente y el conector de Active Directory keytab administrado por el sistema son diferentes modos de implementación que tienen requisitos y pasos diferentes. Cada modo tiene requisitos específicos durante la implementación. Seleccione la pestaña del conector que use.
Para una implementación de keytab administrado por el cliente de Active Directory, debe proporcionar:
- Una cuenta de usuario de Active Directory para SQL
- Nombres de entidad de seguridad de servicio (SPN) en la cuenta de usuario
- Registro A (reenvío) de DNS para el punto de conexión principal de SQL (y, opcionalmente, un punto de conexión secundario)
Preparar la implementación
En función del modo de implementación, complete los pasos siguientes para prepararse para implementar SQL Managed Instance.
Para prepararse para la implementación en el modo keytab administrado por el cliente:
Identifique un nombre DNS para los puntos de conexión de SQL: elija nombres DNS únicos para los puntos de conexión de SQL a los que se conectarán los clientes desde fuera del clúster de Kubernetes.
- Los nombres DNS deben estar en el dominio de Active Directory o en sus dominios descendientes.
- En los ejemplos de este artículo se usa
sqlmi-primary.contoso.local
para el nombre DNS principal ysqlmi-secondary.contoso.local
para el nombre DNS secundario.
Identifique los números de puerto de los puntos de conexión de SQL: escriba un número de puerto para cada uno de los puntos de conexión de SQL.
- Los números de puerto deben estar en el intervalo aceptable de números de puerto para el clúster de Kubernetes.
- En los ejemplos de este artículo se usa
31433
para el número de puerto principal y31434
para el número de puerto secundario.
Cree una cuenta de Active Directory para la instancia administrada: elija un nombre para la cuenta de Active Directory que represente la instancia administrada.
- El nombre debe ser exclusivo en el dominio de Active Directory.
- En los ejemplos de este artículo se usa
sqlmi-account
para el nombre de la cuenta de Active Directory.
Para crear la cuenta:
- En el controlador de dominio, abra la herramienta Usuarios y equipos de Active Directory. Cree una cuenta para representar la instancia administrada.
- Escriba una contraseña de cuenta que cumpla con la directiva de contraseñas de dominio de Active Directory. Usará esta contraseña en algunos de los pasos de las secciones siguientes.
- Asegúrese de que la cuenta está habilitada. La cuenta no necesita ningún permiso especial.
Cree registros DNS para los puntos de conexión de SQL en los servidores DNS de Active Directory: en uno de los servidores DNS de Active Directory, cree registros A (registros de búsqueda directa) para el nombre DNS elegido en el paso 1.
- Los registros DNS deben apuntar a la dirección IP en la que el punto de conexión de SQL escuchará en busca de las conexiones de fuera del clúster de Kubernetes.
- No es necesario crear registros de puntero de búsqueda inversa (PTR) en asociación con los registros A.
Cree SPN: para que SQL pueda aceptar la autenticación de Active Directory en los puntos de conexión de SQL, debe registrar dos SPN en la cuenta que creó en el paso anterior. Se deben registrar dos SPN para el punto de conexión principal. Si quiere la autenticación de Active Directory para el punto de conexión secundario, los SPN también deben registrarse para el punto de conexión secundario.
Para crear y registrar SPN:
Use el siguiente formato para crear los SPN:
MSSQLSvc/<DNS name> MSSQLSvc/<DNS name>:<port>
En uno de los controladores de dominio, ejecute los siguientes comandos para registrar los SPN:
setspn -S MSSQLSvc/<DNS name> <account> setspn -S MSSQLSvc/<DNS name>:<port> <account>
Los comandos pueden tener un aspecto similar al del ejemplo siguiente:
setspn -S MSSQLSvc/sqlmi-primary.contoso.local sqlmi-account setspn -S MSSQLSvc/sqlmi-primary.contoso.local:31433 sqlmi-account
Si quiere la autenticación de Active Directory en el punto de conexión secundario, ejecute los mismos comandos para agregar SPN para el punto de conexión secundario:
setspn -S MSSQLSvc/<DNS name> <account> setspn -S MSSQLSvc/<DNS name>:<port> <account>
Los comandos pueden tener un aspecto similar al del ejemplo siguiente:
setspn -S MSSQLSvc/sqlmi-secondary.contoso.local sqlmi-account setspn -S MSSQLSvc/sqlmi-secondary.contoso.local:31434 sqlmi-account
Genere un archivo keytab que tenga entradas para la cuenta y los SPN: para que SQL pueda autenticarse en Active Directory y aceptar la autenticación de los usuarios de Active Directory, proporcione un archivo keytab mediante un secreto de Kubernetes.
El archivo keytab contiene entradas cifradas para la cuenta de Active Directory que se generó para la instancia administrada y los SPN.
SQL Server usa este archivo como credencial en Active Directory.
Puede elegir entre varias herramientas para generar un archivo keytab:
adutil
: disponible para Linux (consulte Introducción a adutil)ktutil
: disponible en Linuxktpass
: disponible en Windows- Scripts personalizados
Para generar el archivo keytab específicamente para la instancia administrada:
Use uno de estos scripts personalizados:
- Linux: create-sql-keytab.sh
- Windows Server: create-sql-keytab.ps1
Los scripts aceptan varios parámetros y generan un archivo keytab y un archivo de especificación YAML para el secreto de Kubernetes que contiene el archivo keytab.
En el script, reemplace los valores de parámetro por los valores de la implementación de la instancia administrada.
Para los parámetros de entrada, use los valores siguientes:
--realm
: dominio de Active Directory en mayúsculas. Ejemplo:CONTOSO.LOCAL
--account
: la cuenta de Active Directory donde se registran los SPN. Ejemplo:sqlmi-account
--port
: número de puerto del punto de conexión de SQL principal. Ejemplo:31433
--dns-name
: nombre DNS para el punto de conexión de SQL principal.--keytab-file
: ruta de acceso al archivo keytab.--secret-name
: nombre del secreto de keytab para el que se va a generar una especificación.--secret-namespace
: el espacio de nombres de Kubernetes que contiene el secreto keytab.--secondary-port
: número de puerto del punto de conexión de SQL secundario (opcional). Ejemplo:31434
--secondary-dns-name
: nombre DNS para el punto de conexión de SQL secundario (opcional).
Elija un nombre para el secreto de Kubernetes que hospeda el archivo keytab. Use el espacio de nombres donde está implementada la instancia administrada.
Ejecute el siguiente comando para crear una keytab:
AD_PASSWORD=<password> ./create-sql-keytab.sh --realm <Active Directory domain in uppercase> --account <Active Directory account name> --port <endpoint port> --dns-name <endpoint DNS name> --keytab-file <keytab file name/path> --secret-name <keytab secret name> --secret-namespace <keytab secret namespace>
El comando podría tener un aspecto similar al del ejemplo siguiente:
AD_PASSWORD=<password> ./create-sql-keytab.sh --realm CONTOSO.LOCAL --account sqlmi-account --port 31433 --dns-name sqlmi.contoso.local --keytab-file sqlmi.keytab --secret-name sqlmi-keytab-secret --secret-namespace sqlmi-ns
Ejecute el siguiente comando para comprobar que keytab es correcto:
klist -kte <keytab file>
Implemente el secreto de Kubernetes para keytab: use el archivo de especificación de secretos de Kubernetes que creó en el paso anterior para implementar el secreto.
El archivo de especificación tiene un aspecto similar al de este ejemplo:
apiVersion: v1 kind: Secret type: Opaque metadata: name: <secret name> namespace: <secret namespace> data: keytab: <keytab content in Base64>
Para implementar el secreto de Kubernetes, ejecute este comando:
kubectl apply -f <file>
El comando podría tener un aspecto similar al de este ejemplo:
kubectl apply -f sqlmi-keytab-secret.yaml
Establecimiento de propiedades para la autenticación de Active Directory
Para implementar una instancia de SQL Managed Instance habilitada para Azure Arc para la autenticación con Active Directory de Azure Arc, actualice su archivo de especificación de implementación para que haga referencia a la instancia del conector de Active Directory que se va a utilizar. Al hacer referencia al conector de Active Directory en el archivo de especificación de SQL, se configura automáticamente la SQL para la autenticación de Active Directory.
Para admitir la autenticación de Active Directory en SQL en el modo keytab administrado por el cliente, establezca las siguientes propiedades en el archivo de especificación de implementación. Algunas propiedades son obligatorias y otras opcionales.
Obligatorio
spec.security.activeDirectory.connector.name
: nombre del recurso personalizado del conector de Active Directory preexistente que se va a unir para la autenticación de Active Directory. Si escribe un valor para esta propiedad, se implementa la autenticación de Active Directory.spec.security.activeDirectory.accountName
: el nombre de la cuenta de Active Directory para la instancia administrada.spec.security.activeDirectory.keytabSecret
: el nombre del secreto de Kubernetes que hospeda el archivo keytab creado previamente para los usuarios. Este secreto debe estar en el mismo espacio de nombres que la instancia administrada. Este parámetro es necesario sólo para la implementación de Active Directory en el modo de keytab administrado por el cliente.spec.services.primary.dnsName
: escriba un nombre DNS para el punto de conexión de SQL principal.spec.services.primary.port
: escriba un número de puerto para el punto de conexión de SQL principal.
Opcionales
spec.security.activeDirectory.connector.namespace
: espacio de nombres de Kubernetes del conector de Active Directory preexistente que se va a unir para la autenticación de Active Directory. Si no especifica un valor, se usa el espacio de nombres SQL.spec.services.readableSecondaries.dnsName
: escriba un nombre DNS para el punto de conexión de SQL secundario.spec.services.readableSecondaries.port
: escriba un número de puerto para el punto de conexión de SQL secundario.
Preparación del archivo de especificación de implementación
A continuación, prepare un archivo de especificación YAML para implementar SQL Managed Instance. Para el modo que use, escriba los valores de implementación en el archivo de especificación.
Nota:
En el archivo de especificación para ambos modos, el valor admin-login-secret
del ejemplo de YAML proporciona autenticación básica. Puede usar el valor del parámetro para iniciar sesión en la instancia administrada y, a continuación, crear inicios de sesión para usuarios y grupos de Active Directory. Para más información, consulte Conectarse a una instancia de SQL Managed Instance habilitada para Azure Arc integrada en Active Directory.
En el ejemplo siguiente se muestra un archivo de especificación para el modo keytab administrado por el cliente:
apiVersion: v1
data:
password: <your Base64-encoded password>
username: <your Base64-encoded username>
kind: Secret
metadata:
name: admin-login-secret
type: Opaque
---
apiVersion: sql.arcdata.microsoft.com/v3
kind: SqlManagedInstance
metadata:
name: <name>
namespace: <namespace>
spec:
backup:
retentionPeriodInDays: 7
dev: false
tier: GeneralPurpose
forceHA: "true"
licenseType: LicenseIncluded
replicas: 1
security:
adminLoginSecret: admin-login-secret
activeDirectory:
connector:
name: <Active Directory connector name>
namespace: <Active Directory connector namespace>
accountName: <Active Directory account name>
keytabSecret: <keytab secret name>
services:
primary:
type: LoadBalancer
dnsName: <primary endpoint DNS name>
port: <primary endpoint port number>
readableSecondaries:
type: LoadBalancer
dnsName: <secondary endpoint DNS name>
port: <secondary endpoint port number>
storage:
data:
volumes:
- accessMode: ReadWriteOnce
className: local-storage
size: 5Gi
logs:
volumes:
- accessMode: ReadWriteOnce
className: local-storage
size: 5Gi
Actualización de la instancia administrada
Para el modo keytab administrado por el cliente y el modo keytab administrado por el sistema, implemente la instancia administrada mediante el archivo YAML de especificación preparada:
Guarde el archivo. En el ejemplo del paso siguiente se usa sqlmi.yaml para el nombre de archivo de especificación, pero puede elegir cualquier nombre de archivo.
Ejecute el siguiente comando para implementar la instancia con la especificación:
kubectl apply -f <specification file name>
El comando podría tener un aspecto similar al del ejemplo siguiente:
kubectl apply -f sqlmi.yaml