Ingress Controller de Citrix ADC

Directivas de autenticación y autorización para Kubernetes con Citrix ADC

Las directivas de autenticación y autorización se utilizan para aplicar restricciones de acceso a los recursos alojados por un servidor de aplicaciones o API. Si bien puede verificar la identidad mediante las directivas de autenticación, las directivas de autorización se utilizan para verificar si una solicitud especificada tiene los permisos necesarios para acceder a un recurso.

Citrix proporciona una CustomResourceDefinition (CRD) de Kubernetes denominada CRD de autenticación que puede usar con el Citrix Ingress Controller para definir directivas de autenticación en Citrix ADC de entrada.

Definición de CRD de autenticación

La CRD de autenticación está disponible en el repositorio de GitHub Citrix Ingress Controller en: auth-crd.yaml. La CRD de autenticación proporciona atributos para las diversas opciones que se requieren para definir las directivas de autenticación en el Citrix ADC de entrada.

Atributos de CRD de autenticación

La CRD de autenticación proporciona los siguientes atributos que se utilizan para definir las directivas de autenticación:

  • servicenames
  • authentication_mechanism
  • authentication_providers
  • authentication_policies
  • authorization_policies

Nombres de servicio

El nombre de los servicios para los que se deben aplicar las directivas de autenticación y autorización.

Mecanismo de autenticación

Se admiten los siguientes mecanismos de autenticación:

  • Usar encabezados de solicitud:
    permite la autenticación de usuarios mediante el encabezado de solicitud. Puede utilizar este mecanismo cuando las credenciales o las claves de API se transfieren en un encabezado (normalmente encabezado de autorización). Por ejemplo, puede usar la autenticación mediante encabezados de solicitud para claves básicas, de resumen, de portador o de API.

  • Uso de formularios: puede utilizar este mecanismo con autenticación de usuario o web, incluida la configuración de la parte de confianza para OpenID connect y la configuración del proveedor de servicios para SAML.

Cuando no se especifica el mecanismo de autenticación, el valor predeterminado es la autenticación mediante el encabezado de solicitud.

A continuación se muestran los atributos de la autenticación basada en formularios.

Atributo Descripción
authentication_host Especifica un nombre de dominio completo (FQDN) al que se debe redirigir al usuario para el servicio de autenticación ADC. Este FQDN debe ser único y debe resolverse en la dirección IP front-end de Citrix ADC con el tipo de ingreso/servicio LoadBalancer o la dirección VIP de Listener CRD.
authentication_host_cert Especifica el nombre del certificado SSL que se va a utilizar con authentication_host. Este certificado es obligatorio al realizar la autenticación mediante el formulario.
ingress_name Especifica el nombre de Ingress para el que se aplica la autenticación mediante formularios.
lb_service_name Especifica el nombre del servicio de tipo LoadBalancer para el que se aplica la autenticación mediante formularios.
listener_name El nombre de la CRD de Listener para la que se aplica la autenticación mediante formularios.
vip Especifica la dirección IP front-end del Ingress para el que se aplica la autenticación mediante formularios. Este atributo se refiere a la dirección frontend-ip proporcionada con el Ingress. Si hay más de un recurso de Ingress que usa la misma frontend-ip, se recomienda usar vip.

Nota:

  • Al usar formularios, la autenticación se puede habilitar para todos los tipos de tráfico. Actualmente, no se admite la autenticación granular.

  • Según el recurso al que necesite aplicar la autenticación basada en formularios, puede usar uno de los atributos ingress_name, lb_service_name, listener_name o vip para especificar el recurso.

Proveedores de autenticación

Los proveedores definen el mecanismo de autenticación y los parámetros que se requieren para el mecanismo de autenticación.

Autenticación

Especifica que la autenticación local se usa con el esquema de autenticación básica HTTP. Para usar la autenticación básica, debe crear cuentas de usuario en el Citrix ADC de entrada.

Autenticación OAuth

El mecanismo de autenticación de OAuth requiere que un proveedor de identidad externo autentique al cliente mediante OAuth2 y emita un token de acceso. Cuando el cliente presenta el token de acceso a un Citrix ADC como credencial de acceso, Citrix ADC valida el token con los valores configurados. Si la validación del token se realiza correctamente, Citrix ADC concede acceso al cliente.

Atributos de autenticación OAuth

Los siguientes son los atributos de la autenticación de OAuth:

Atributo Descripción
Issuer La identidad (normalmente una URL) del servidor cuyos tokens deben aceptarse para la autenticación.
jwks_uri La URL del extremo que contiene JWK (clave web JSON) para la verificación JWT (token web JSON).
audience La identidad del servicio o la aplicación para los que se aplica el token.
token_in_hdr El nombre de encabezado personalizado en el que está presente el token. El valor predeterminado es el encabezado Authorization.
  Nota: Puede especificar más de un encabezado.
token_in_param El parámetro de consulta en el que está presente el token.
signature_algorithms Especifica la lista de algoritmos de firma que se permiten. De forma predeterminada, se permiten los algoritmos HS256, RS256 y RS512.
introspect_url La URL del extremo de introspección del servidor de autenticación (IdP). Si el testigo de acceso presentado es un testigo opaco, se utiliza la introspección para la verificación del testigo.
client_credentials El nombre del objeto de secretos de Kubernetes que contiene el identificador de cliente y el secreto de cliente necesarios para autenticarse en el servidor de autenticación.
claims_to_save La lista de reclamaciones que se van a guardar. Las reclamaciones se utilizan para crear directivas de autorización.

OpenID Connect (OIDC) es una capa de identidad simple en la parte superior del protocolo OAuth 2.0. OIDC permite a los clientes verificar la identidad del usuario final en función de la autenticación realizada por un servidor de autorización, así como obtener información de perfil básica sobre el usuario final. Además de los atributos de OAuth, puede usar los siguientes atributos para configurar OIDC.

Atributo Descripción
metadata_url Especifica la URL que se usa para obtener metadatos de proveedores de OAUTH u OIDC.
user_field Especifica el atributo del token del que se debe extraer el nombre de usuario. De forma predeterminada, Citrix ADC examina el atributo de correo electrónico para el ID de usuario.
default_group Especifica el grupo asignado a la solicitud si la autenticación se realiza correctamente. Este grupo se suma a los grupos extraídos del token.
grant_type Permite especificar el tipo de flujo hasta el punto final del token. El valor predeterminado es CODE.
pkce Especifica si se debe habilitar la clave de prueba para el intercambio de código (PKCE). El valor predeterminado es ENABLED.
token_ep_auth_method Especifica el método de autenticación que se utilizará con el punto final del token. El valor predeterminado es client_secret_post.

Autenticación SAML

El lenguaje de marcado de aserciones de seguridad (SAML) es un estándar abierto basado en XML que permite la autenticación de usuarios en todos los productos u organizaciones. El mecanismo de autenticación SAML requiere un proveedor de identidad externo para autenticar al cliente. SAML funciona transfiriendo la identidad del cliente del proveedor de identidades a Citrix ADC. Al validar correctamente la identidad del cliente, Citrix ADC concede acceso al cliente.

A continuación se muestran los atributos de la autenticación SAML.

Atributo Descripción
metadata_url Especifica la URL que se utiliza para obtener metadatos SAML.
metadata_refresh_interval Especifica el intervalo en minutos para obtener metadatos de la URL de metadatos especificada.
signing_cert Especifica el certificado SSL para firmar solicitudes del proveedor de servicios (SP) al proveedor de identidad (IdP).
audience Especifica la identidad del servicio o la aplicación para los que se aplica el token.
issuer_name Especifica el nombre utilizado en las solicitudes enviadas desde el SP al IdP para identificar el Citrix ADC.
binding Especifica el mecanismo de transporte del mensaje SAML. El valor predeterminado es POST.
artifact_resolution_service_url Especifica la URL del servicio de resolución de artefactos en el IdP.
logout_binding Especifica el mecanismo de transporte del cierre de sesión de SAML. El valor predeterminado es POST.
reject_unsigned_assertion Rechaza las afirmaciones de SAML sin firmar. Si este valor es ON, rechaza la afirmación sin firma.
user_field Especifica el ID de usuario SAML especificado en la aserción SAML
default_authentication_group Especifica el grupo predeterminado que se elige cuando la autenticación se realiza correctamente, además de los grupos extraídos.
skewtime Especifica el tiempo de desviación de reloj permitido en minutos en una aserción SAML entrante.
attributes_to_save Especifica la lista de nombres de atributo separados por comas que deben extraerse y almacenarse como pares clave-valor para la sesión en Citrix ADC.

Autenticación LDAP

LDAP (Lightweight Directory Access Protocol) es un protocolo de aplicación abierto, independiente del proveedor y estándar de la industria para acceder y mantener servicios de información de directorios distribuidos a través de una red de Protocolo de Internet (IP). Un uso común de LDAP es proporcionar un lugar central para almacenar nombres de usuario y contraseñas. LDAP permite que muchas aplicaciones y servicios diferentes se conecten al servidor LDAP para validar a los usuarios.

Nota:

La autenticación LDAP se admite a través de los mecanismos de autenticación que utilizan el encabezado de solicitud o mediante formularios.

A continuación se muestran los atributos de la autenticación LDAP.

Atributo Descripción
server_ip Especifica la dirección IP asignada al servidor LDAP.
server_name Especifica el nombre del servidor LDAP como un FQDN.
server_port Especifica el puerto en el que el servidor LDAP acepta conexiones. El valor por defecto es 389.
base Especifica el nodo base en el que se inician las búsquedas LDAP. Si el servidor LDAP se ejecuta localmente, el valor predeterminado de base es dc=netscaler, dc=com.
server_login_credentials Especifica el objeto secreto de Kubernetes que proporciona credenciales para iniciar sesión en el servidor LDAP. Los datos secretos deben tener nombre de usuario y contraseña.
login_name Especifica el atributo LDAP login name. Citrix ADC utiliza el nombre de inicio de sesión LDAP para consultar servidores LDAP externos o Active Directories.
security_type Especifica el tipo de seguridad que se utiliza para las comunicaciones entre Citrix ADC y el servidor LDAP. El valor predeterminado es TLS.
validate_server_cert Valida los certificados del servidor LDAP. El valor predeterminado es NO.
hostname Especifica el nombre de host del servidor LDAP. Si validate_server_cert es ON, este valor debe ser el nombre de host en el certificado del LDAP. Una discrepancia en el nombre de host provoca un error de conexión.
sub_attribute_name Especifica el nombre del subatributo del grupo LDAP. Este atributo se usa para la extracción de grupos del servidor LDAP.
group_attribute_name Especifica el nombre del atributo del grupo LDAP. Este atributo se usa para la extracción de grupos en el servidor LDAP.
search_filter Especifica la cadena que se va a combinar con la cadena de búsqueda de usuarios LDAP predeterminada para formar el valor de búsqueda. Por ejemplo, si el filtro de búsqueda “vpnallowed=true” se combina con el nombre de inicio de sesión LDAP “samaccount” y el nombre de usuario proporcionado por el usuario es “bob”, el resultado es la cadena de búsqueda LDAP “” (& (vpnallowed=true) (samaccount=bob) “”. Escriba la cadena de búsqueda entre dos juegos de comillas dobles.
auth_timeout Especifica el número de segundos que Citrix ADC espera una respuesta del servidor. El valor por defecto es 3.
password_change Permite solicitudes de cambio de contraseña. El valor predeterminado es DISABLED.
attributes_to_save Lista de nombres de atributo separados por comas que deben obtenerse del servidor LDAP y almacenarse como pares clave-valor para la sesión en Citrix ADC.

Directivas de autenticación

Las authentication_policies le permiten definir los criterios de selección de tráfico para aplicar el mecanismo de autenticación y también especificar el proveedor que quiere usar para el tráfico seleccionado.

La directiva de autenticación admite dos formatos a través de los cuales puede especificar reglas de autenticación:

  • formato de recursos
  • formato de expresión

Los siguientes son los atributos de las directivas con formato de recursos:

Atributo Descripción
path Conjunto de prefijos de ruta de URL que hacen referencia a un punto de enlace de API específico. Por ejemplo, /api/v1/products/.
method Un conjunto de métodos HTTP. Los valores permitidos son GET, PUT, POST o DELETE. El tráfico se selecciona si el URI de la solicitud entrante coincide con cualquiera de las rutas y cualquiera de los métodos enumerados. Si no se especifica el método, solo se utiliza la ruta para los criterios de selección de tráfico.
provider Especifica el mecanismo de autenticación que se debe utilizar. Si no se proporciona el mecanismo de autenticación, entonces no se lleva a cabo la autenticación.

Los siguientes atributos son para las directivas de autenticación con formato de expresión:

Atributo Descripción
expression Especifica la expresión de Citrix ADC que se evaluará en función de la autenticación
provider Especifica el mecanismo de autenticación que se debe utilizar. Si no se proporciona el mecanismo de autenticación, entonces no se lleva a cabo la autenticación.

Nota:

Si quiere omitir la autenticación para un punto final específico, cree una directiva con el atributo provider establecido como lista vacía. De lo contrario, se rechaza la solicitud.

Directivas de autorización

Las directivas de autorización le permiten definir los criterios de selección de tráfico para aplicar los requisitos de autorización para el tráfico seleccionado.

La directiva de autorización admite dos formatos a través de los cuales puede especificar las reglas de autorización:

  • formato de recursos
  • formato de expresión

Los siguientes son los atributos de las directivas de autorización con formato de recurso:

Atributo Descripción
path Conjunto de prefijos de ruta de URL que hacen referencia a un punto de enlace de API específico. Por ejemplo, /api/v1/products/.
method Un conjunto de métodos HTTP. Los valores permitidos son GET, PUT, POST o DELETE.
claims Especifica las notificaciones necesarias para acceder a un punto de enlace de API específico. name indica el nombre de la reclamación y values indica los permisos requeridos. Puede tener más de un reclamo. Si se especifica una lista vacía, implica que no se requiere autorización.
  Nota: Cualquier reclamación que deba usarse para la autorización debe guardarse como parte de la autenticación.

Los siguientes son los atributos de las directivas de autorización con formato de expresión:

Atributo Descripción
expression Especifica una expresión que se va a evaluar para la autorización.

Nota:

Citrix ADC requiere directivas de autenticación y autorización para el tráfico de la API. Por lo tanto, debe configurar una directiva de autorización con una directiva de autenticación. Incluso si no tiene ninguna comprobación de autorización, debe crear una directiva de autorización con reclamaciones vacías. De lo contrario, la solicitud se deniega con un error 403.

Nota:

La autorización se realizará correctamente si la solicitud entrante coincide con una directiva (ruta, método y notificaciones). Todas las directivas se prueban hasta que haya una coincidencia. Si se requiere omitir selectivamente la autorización para un punto final específico, se debe crear una directiva explícita.

Implementar la CRD de autenticación

Realice lo siguiente para implementar la CRD de autenticación:

  1. Descargue el CRD (auth-crd.yaml).

  2. Implemente la CRD de autenticación con el siguiente comando:

    kubectl create -f auth-crd.yaml
    

    Por ejemplo:

    root@master:~# kubectl create -f auth-crd.yaml
    
    customresourcedefinition.apiextensions.k8s.io/authpolicies.citrix.com created
    

Cómo escribir directivas de autenticación y autorización

Después de implementar la CRD proporcionada por Citrix en el clúster de Kubernetes, puede definir la configuración de la directiva de autenticación en un archivo .yaml. En el archivo .yaml, use authpolicy en el campo kind y en la sección spec agregue los atributos de Auth CRD según sus requisitos para la configuración de la directiva.

Después de implementar el archivo .yaml, el Citrix Ingress Controller aplica la configuración de la directiva de autenticación en el dispositivo Citrix ADC de entrada.

Proveedor de autenticación local

A continuación, se muestra un ejemplo de definición de directiva de autenticación y autorización para el tipo de proveedor de autenticaciónlocal (local_auth.yaml).

  apiVersion: citrix.com/v1beta1
  kind: authpolicy
  metadata:
    name: authexample
  spec:
      servicenames:
      - frontend

      authentication_providers:
          - name: "local-auth-provider"
            basic_local_db:
                use_local_auth: 'YES'

      authentication_policies:
          - resource:
              path:
                - '/orders/'
                - '/shipping/'
              method: [GET, POST]
            provider: ["local-auth-provider"]
          
          # skip authentication for this
          - resource:
              path:
                - '/products/'
              method: [GET]
            provider: []

      authorization_policies:
          # skip authorization
          - resource:
              path: []
              method: []
              claims: []

La definición de directiva de ejemplo lleva a cabo lo siguiente:

  • Citrix ADC realiza la autenticación local en las solicitudes a lo siguiente:
    • OperaciónGET o POST en pedidos y puntos finales de envío.
  • Citrix ADC no realiza la autenticación para la operación GET en el dispositivo de punto final products.
  • Citrix ADC no aplica ningún permiso de autorización.

Verificación JWT de OAuth

A continuación, se muestra un ejemplo de definición de directiva de autenticación y autorización para la verificación JWT de OAuth (oauth_jwt_auth.yaml).

apiVersion: citrix.com/v1beta1
kind: authpolicy
metadata:
  name: authexample
spec:
    servicenames:
    - frontend

    authentication_providers:
      - name: "jwt-auth-provider"
        oauth:
          issuer: "https://sts.windows.net/tenant1/"
          jwks_uri: "https://login.microsoftonline.com/tenant1/discovery/v2.0/keys"
          audience : ["https://api.service.net"]
          claims_to_save : ["scope"]

    authentication_policies:
        - resource:
            path:
              - '/orders/'
              - '/shipping/'
            method: [GET, POST]
          provider: ["jwt-auth-provider"]
        
        # skip authentication for this
        - resource:
            path:
              - '/products/'
            method: [GET]
          provider: []

    authorization_policies:
        - resource:
            path:
              - '/orders/'
              - '/shipping/'
            method: [POST]
            claims: 
              - name: "scope"
                values: ["read", "write"]
        - resource:
            path:
              - '/orders/'
            method: [GET]
            claims: 
              - name: "scope"
                values: ["read"]
        # skip authorization, no claims required
        - resource:
            path:
              - '/shipping/'
            method: [GET]
            claims: []

La definición de directiva de ejemplo lleva a cabo lo siguiente:

  • Citrix ADC realiza la verificación JWT en las solicitudes a lo siguiente:

    • La operación GET o POST en los puntos finales de pedidos y envíos .
  • Citrix ADC omite la autenticación para la operación GET en el dispositivo de punto final products.

  • Citrix ADC requiere la notificación de ámbito con los permisos read y write para la operación POST en los dispositivos de punto final orders y shipping.

  • Citrix ADC requiere la notificación de alcance con el permiso de lectura para la operación GET en el dispositivo de punto final orders.

  • Citrix ADC no necesita ningún permiso para la operación GET en el dispositivo de punto final shipping.

Para OAuth, si el token está presente en un encabezado personalizado, se puede especificar mediante el atributo token_in_hdr de la siguiente manera:

      oauth:
        issuer: "https://sts.windows.net/tenant1/"
        jwks_uri: "https://login.microsoftonline.com/tenant1/discovery/v2.0/keys"
        audience : ["https://vault.azure.net"]
        token_in_hdr : [“custom-hdr1”]

Del mismo modo, si el token está presente en un parámetro de consulta, se puede especificar mediante el atributo token_in_param de la siguiente manera:

      oauth:
        issuer: "https://sts.windows.net/tenant1/"
        jwks_uri: "https://login.microsoftonline.com/tenant1/discovery/v2.0keys"
        audience : ["https://vault.azure.net"]
        token_in_param : [“query-param1”]

Introspección de OAuth

A continuación, se muestra un ejemplo de definición de directiva de autenticación y autorización para la verificación JWT de OAuth. (oauth_intro_auth.yaml)

  apiVersion: citrix.com/v1beta1
  kind: authpolicy
  metadata:
    name: authexample
  spec:
      servicenames:
      - frontend

      authentication_providers:
          - name: "introspect-provider"
            oauth:
              issuer: "ns-idp"
              jwks_uri: "https://idp.aaa/oauth/idp/certs"
              audience : ["https://api.service.net"]
              client_credentials: "oauthsecret"
              introspect_url: https://idp.aaa/oauth/idp/introspect
              claims_to_save : ["scope"]

      authentication_policies:
          - resource:
              path: []
              method: []
            provider: ["introspect-provider"]
          
      authorization_policies:
          - resource:
              path: []
              method: [POST]
              claims: 
              - name: "scope"
                values: ["read", "write"]
          - resource:
              path: []
              method: [GET]
              claims: 
              - name: "scope"
                values: ["read"]

La definición de directiva de ejemplo lleva a cabo lo siguiente:

  • Citrix ADC realiza la introspección de OAuth como se especifica en el proveedor introspect-provider para todas las solicitudes.

  • Citrix ADC requiere la declaración de ámbito con los permisos read y write para todas las solicitudes POST.

  • Citrix ADC requiere la declaración de ámbito con el permiso de lectura para todas las solicitudes GET.

Crear un objeto secrets con credenciales de cliente para introspección

Se necesita un objeto de secretos de Kubernetes para configurar la introspección de OAuth. Puede crear un objeto secreto de forma similar a la que se muestra en el siguiente ejemplo:

apiVersion: v1        
kind: Secret          
metadata:             
  name: oauthsecret
type: Opaque        
stringData:           
 client_id: "nsintro"
 client_secret: "nssintro"

Nota:

Las claves del objeto secreto opaco deben ser client_id y client_secret. Un usuario puede establecer los valores para ellos según lo quiera.

Autenticación SAML mediante formularios

A continuación se muestra un ejemplo de autenticación SAML mediante formularios. En el ejemplo, authhost-tls-cert-secret y saml-tls-cert-secret son secretos TLS de Kubernetes que hacen referencia al certificado y la clave.

Nota:

Cuando certkey.cert y certkey.key son el certificado y la clave respectivamente para el host de autenticación, authhost-tls-cert-secret se pueden formar mediante el siguiente comando:

     kubectl create secret tls authhost-tls-cert-secret --key="certkey.key" --cert="certkey.cert

Del mismo modo, puede usar este comando para formar saml-tls-cert-secret con el certificado y la clave requeridos.


apiVersion: citrix.com/v1beta1
kind: authpolicy
metadata:
  name: samlexample
spec:
    servicenames:
    - frontend

    authentication_mechanism:
      using_forms:
        authentication_host: "fqdn_authenticaton_host"
        authentication_host_cert:
          tls_secret: authhost-tls-cert-secret
        listener_name: “example-listener”

    authentication_providers:
        - name: "saml-auth-provider"
          saml:
              metadata_url: "https://idp.aaa/metadata/samlidp/aaa"
              signing_cert:
                  tls_secret: saml-tls-cert-secret

    authentication_policies:

        - resource:
            path: []
            method: []
          provider: ["saml-auth-provider"]

    authorization_policies:

        - resource:
            path: []
            method: []
            claims: []

<!--NeedCopy-->

La definición de directiva de ejemplo lleva a cabo lo siguiente:

  • Citrix ADC realiza la autenticación SAML según lo especificado en el proveedor saml-auth-provider para todas las solicitudes. Nota: La autenticación granular no es compatible con el mecanismo de formularios.

  • Citrix ADC requiere la notificación de grupo con el permiso admin para todas las solicitudes POST.

  • Citrix ADC no requiere ningún permiso específico para las solicitudes GET.

Autenticación OpenID Connect mediante formularios

A continuación, se muestra un ejemplo de creación de autenticación OpenID Connect para configurar Citrix ADC en una función de parte de retransmisión (RP) para autenticar a los usuarios para un proveedor de identidad externo. authentication_mechanism debe configurarse en using_forms para desencadenar los procedimientos de OpenID Connect.

apiVersion: citrix.com/v1beta1
kind: authpolicy
metadata:
  name: authoidc
spec:
    servicenames:
    - frontend
    authentication_mechanism:
        using_forms:
            authentication_host: "10.221.35.213"
            authentication_host_cert:
                 tls_secret: "oidc-tls-secret"
            ingress_name:  “example-ingress”

    authentication_providers:

        - name: "oidc-provider"
          oauth:
            audience : ["https://app1.citrix.com"]
            client_credentials: "oidcsecret"
            metadata_url: "https://10.221.35.214/oauth/idp/.well-known/openid-configuration"
            default_group: "groupA"
            user_field: "sub"
            pkce: "ENABLED"
            token_ep_auth_method: "client_secret_post"

    authentication_policies:

        - resource:
            path: []
            method: []
          provider: ["oidc-provider"]

    authorization_policies:

        #default - no authorization requirements
        - resource:
            path: []
            method: []
            claims: []
<!--NeedCopy-->

La definición de directiva de ejemplo lleva a cabo lo siguiente:

  • Citrix ADC realiza la autenticación OIDC (parte de confianza) como se especifica en el proveedor oidc-provider para todas las solicitudes.

    Nota: La autenticación granular no es compatible con el mecanismo de formularios.

  • Citrix ADC no requiere ningún permiso de autorización.

Autenticación LDAP con encabezado de solicitud

A continuación, se muestra un ejemplo de autenticación LDAP mediante el encabezado de solicitud.

En este ejemplo, ldapcredential es el secreto de Kubernetes que hace referencia a las credenciales del servidor LDAP. Consulte el archivo ldap_secret.yaml para obtener información sobre cómo crear credenciales de servidor LDAP.


apiVersion: citrix.com/v1beta1
kind: authpolicy
metadata:
  name: ldapexample
spec:
    servicenames:
    - frontend

    authentication_providers:
        - name: "ldap-auth-provider"
          ldap:
              server_ip: "192.2.156.160"
              base: 'dc=aaa,dc=local'
              login_name: accountname
              sub_attribute_name: CN
              server_login_credentials: ldapcredential

        - name: "local-auth-provider"
          basic_local_db:
              use_local_auth: 'YES'

    authentication_policies:

        - resource:
            path: []
            method: []
          provider: ["ldap-auth-provider"]


    authorization_policies:

        - resource:
            path: []
            method: []
            claims: []
<!--NeedCopy-->

Nota: Con el mecanismo de autenticación basada en encabezado de solicitud, se admite la autenticación granular basada en el tráfico.

autenticación LDAP mediante formularios

En el ejemplo authhost-tls-cert-secret está el secreto TLS de Kubernetes que hace referencia al certificado y la clave.

Cuando certkey.cert y certkey.key son el certificado y la clave respectivamente para el host de autenticación, authhost-tls-cert-secret se pueden formar mediante el siguiente comando:

    kubectl create secret tls authhost-tls-cert-secret --key="certkey.key" --cert="certkey.cert

En este ejemplo, ldapcredential es el secreto de Kubernetes que hace referencia a las credenciales del servidor LDAP. Consulte el archivo ldap_secret.yaml para obtener información sobre cómo crear credenciales de servidor LDAP.

apiVersion: citrix.com/v1beta1
kind: authpolicy
metadata:
  name: ldapexample
spec:
    servicenames:
    - frontend

    authentication_mechanism:
      using_forms:
        authentication_host: "fqdn_authenticaton_host"
        authentication_host_cert:
          tls_secret: authhost-tls-cert-secret
        vip: "192.2.156.156"

    authentication_providers:
        - name: "ldap-auth-provider"
          ldap:
              server_ip: "192.2.156.160"
              base: 'dc=aaa,dc=local'
              login_name: accountname
              sub_attribute_name: CN
              server_login_credentials: ldapcredential

    authentication_policies:

        - resource:
            path: []
            method: []
          provider: ["ldap-auth-provider"]

    authorization_policies:

        - resource:
            path: []
            method: []
            claims: []

<!--NeedCopy-->

La definición de directiva de ejemplo lleva a cabo lo siguiente:

  • Citrix ADC realiza la autenticación LDAP para todo el tráfico (todas las solicitudes).
  • Citrix ADC no aplica ningún permiso de autorización.

A continuación se muestra un ejemplo de LDAP_secret.yaml.

apiVersion: v1
kind: Secret
metadata:
  name: ldapcredential
type: Opaque
stringData:
  username: 'ldap_server_username'
  password: 'ldap_server_password'

<!--NeedCopy-->

Ejemplo de compatibilidad de expresiones de Citrix ADC con Auth CRD

En este ejemplo se muestra cómo puede especificar expresiones de Citrix ADC junto con las directivas de autenticación y autorización:

  apiVersion: citrix.com/v1beta1
  kind: authpolicy
  metadata:
    name: authexample
  spec:
      servicenames:
      - frontend

      authentication_mechanism:
        using_request_header: 'ON'

      authentication_providers:
          - name: "ldap-auth-provider"
            ldap:              
                server_ip: "192.2.156.160"
                base: 'dc=aaa,dc=local'
                login_name: accountname
                sub_attribute_name: CN
                server_login_credentials: ldapcredential
                # "memberof" attribute details are extracted from LDAP server.
                attributes_to_save: memberof

      authentication_policies:
          # Perform LDAP authentication for the host hotdrink.beverages.com
          - expression: 'HTTP.REQ.HOSTNAME.SET_TEXT_MODE(IGNORECASE).EQ("hotdrink.beverages.com")'
            provider: ["ldap-auth-provider"]


      authorization_policies:
          # ALLOW the session only if the authenticated user is associated with attribute "memberof" having value "grp4"
          - expression: 'aaa.user.attribute("memberof").contains("grp4")'
Directivas de autenticación y autorización para Kubernetes con Citrix ADC