NetScaler Ingress Controller

Directivas de autenticación y autorización para Kubernetes con NetScaler

May 10, 2023

Contribución de:

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.

NetScaler proporciona una CustomResourceDefinition (CRD) de Kubernetes denominada CRD de autenticación que puede usar con el NetScaler Ingress Controller de NetScaler para definir políticas de autenticación en el NetScaler de entrada.

Definición de CRD de autenticación

El CRD de autenticación está disponible en el repositorio GitHub de NetScaler 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 NetScaler 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 NetScaler 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 NetScaler 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 NetScaler como credencial de acceso, NetScaler valida el token con los valores configurados. Si la validación del token se realiza correctamente, NetScaler 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, NetScaler 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 NetScaler. Al validar correctamente la identidad del cliente, NetScaler 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 NetScaler.
`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 NetScaler.

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. NetScaler 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 NetScaler 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 NetScaler 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 NetScaler.

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 NetScaler 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:

NetScaler 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 política de autorización con solicitudes 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:

Descargue el CRD (auth-crd.yaml).

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 el CRD proporcionado por NetScaler en el clúster de Kubernetes, puede definir la configuración de la política 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.

Tras implementar el .yaml archivo, el NetScaler Ingress Controller aplica la configuración de la política de autenticación en el dispositivo Ingress NetScaler.

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:

NetScaler realiza la autenticación local en las solicitudes a lo siguiente:
- OperaciónGET o POST en pedidos y puntos finales de envío.
NetScaler no realiza la autenticación para la operación GET en el dispositivo de punto final products.
NetScaler 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:

NetScaler 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 .
NetScaler omite la autenticación para la operación GET en el dispositivo de punto final products.
NetScaler 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.
NetScaler requiere la notificación de alcance con el permiso de lectura para la operación GET en el dispositivo de punto final orders.
NetScaler 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:

NetScaler realiza la introspección de OAuth como se especifica en el proveedor introspect-provider para todas las solicitudes.
NetScaler requiere la declaración de ámbito con los permisos read y write para todas las solicitudes POST.
NetScaler 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:

NetScaler 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.
NetScaler requiere la notificación de grupo con el permiso admin para todas las solicitudes POST.
NetScaler 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 NetScaler 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:

NetScaler 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.
NetScaler 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

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:

NetScaler realiza la autenticación LDAP para todo el tráfico (todas las solicitudes).
NetScaler 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 NetScaler con Auth CRD

En este ejemplo se muestra cómo puede especificar expresiones de NetScaler 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")'

La versión oficial de este contenido está en inglés. Para mayor comodidad, parte del contenido de la documentación de Cloud Software Group solo tiene traducción automática. Cloud Software Group no puede controlar el contenido con traducción automática, que puede contener errores, imprecisiones o un lenguaje inadecuado. No se ofrece ninguna garantía, ni implícita ni explícita, en cuanto a la exactitud, la fiabilidad, la idoneidad o la precisión de las traducciones realizadas del original en inglés a cualquier otro idioma, o que su producto o servicio de Cloud Software Group se ajusten a cualquier contenido con traducción automática, y cualquier garantía provista bajo el contrato de licencia del usuario final o las condiciones de servicio, o cualquier otro contrato con Cloud Software Group, de que el producto o el servicio se ajusten a la documentación no se aplicará en cuanto dicha documentación se ha traducido automáticamente. Cloud Software Group no se hace responsable de los daños o los problemas que puedan surgir del uso del contenido traducido automáticamente.

¿Le ha resultado útil?

Directivas de autenticación y autorización para Kubernetes con NetScaler

May 10, 2023

Contribución de:

May 10, 2023

Contribución de:

En este artículo

Definición de CRD de autenticación
Atributos de CRD de autenticación
Implementar la CRD de autenticación
Cómo escribir directivas de autenticación y autorización

¿Le ha resultado útil?