Configuración de las credenciales y la autenticación de CDN cdn-credentials-authentication

NOTE
Esta función aún no está disponible de forma general. Para unirse al programa de adopción anticipada, envíe un correo electrónico a aemcs-cdn-config-adopter@adobe.com.

La CDN proporcionada por la Adobe tiene varias funciones y servicios, algunos de los cuales dependen de las credenciales y la autenticación para garantizar un nivel adecuado de seguridad empresarial. Al declarar reglas en un archivo de configuración implementado mediante la Canalización de configuración de Cloud Manager, los clientes pueden configurar, en forma de autoservicio, lo siguiente:

  • Valor del encabezado HTTP utilizado por la CDN de Adobe para validar solicitudes procedentes de una CDN administrada por el cliente.
  • El token de API utilizado para purgar recursos en la caché de CDN.
  • Una lista de combinaciones de nombre de usuario y contraseña que pueden acceder al contenido restringido enviando un formulario de autenticación básica.

Cada uno de ellos, incluida la sintaxis de configuración, se describe en su propia sección a continuación. La sección Configuración común ilustra la configuración común a ambas, así como a la implementación. Finalmente, hay una sección sobre cómo rotar claves, lo cual se considera una buena práctica de seguridad.

Valor del encabezado HTTP de CDN administrado por el cliente CDN-HTTP-value

Como se describe en la página CDN en AEM as a Cloud Service, los clientes pueden elegir enrutar el tráfico a través de su propia CDN, que se denomina CDN del cliente (también denominada a veces BYOCDN).

Como parte de la configuración, la CDN de Adobe y la CDN del cliente deben acordar un valor del encabezado HTTP X-AEM-Edge-Key. Este valor se establece en cada solicitud, en la red de distribución de contenido (CDN) del cliente, antes de enrutarse a la red de distribución de contenido (CDN) de Adobe AEM, la cual valida que el valor es el esperado, de modo que puede confiar en otros encabezados HTTP, incluidos los que ayudan a enrutar la solicitud a la red de distribución de contenido (CDN) adecuada.

El valor X-AEM-Edge-Key se declara con la sintaxis siguiente, con los valores reales a los que hacen referencia las propiedades edgeKey1 y edgeKey2. Consulte la sección Configuración común para obtener información sobre cómo implementar la configuración.

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  experimental_authentication:
    authenticators:
      - name: edge-auth
        type: edge
        edgeKey1: ${{CDN_EDGEKEY_052824}}
        edgeKey2: ${{CDN_EDGEKEY_041425}}
    rules:
      - name: edge-auth-rule
        when: { reqProperty: tier, equals: "publish" }
        action:
          type: authenticate
          authenticator: edge-auth

La sintaxis del valor X-AEM-Edge-Key incluye:

  • Tipo, versión y metadatos.

  • Nodo de datos que contiene un nodo experimental_authentication secundario (el prefijo experimental se quitará cuando se libere la característica).

  • En experimental_authentication, un nodo authenticators y un nodo rules, ambos son matrices.

  • Autenticadores: Permite declarar un tipo de token o credencial, que en este caso es una clave perimetral. Incluye las siguientes propiedades:

    • name: una cadena descriptiva.
    • type: debe ser edge.
    • AEM edgeKey1: el valor de X–Edge-Key, que debe hacer referencia a un token secreto, que no debería almacenarse en Git, sino que debería declararse como variable de entorno de Cloud Manager de tipo secreto. En el campo Servicio aplicado, seleccione Todo. Se recomienda que el valor (por ejemplo,${{CDN_EDGEKEY_052824}}) refleje el día en que se agregó.
    • edgeKey2: se usa para la rotación de secretos, que se describe en la sección de rotación de secretos a continuación. Definirlo de manera similar a edgeKey1. Se debe declarar al menos uno de edgeKey1 y edgeKey2.
  • Reglas: le permite declarar cuál de los autenticadores debe utilizarse y si es para el nivel de publicación o vista previa. Incluye:

    • name: una cadena descriptiva.
    • when: una condición que determina cuándo se debe evaluar la regla, según la sintaxis del artículo Reglas de filtro de tráfico. Normalmente, incluirá una comparación del nivel actual (por ejemplo, publicación), de modo que todo el tráfico en directo se valida como enrutamiento a través de la CDN del cliente.
    • action: debe especificar "authentication", con referencia al autenticador deseado.
NOTE
La clave de Edge debe configurarse como una variable Cloud Manager Environment Variable de tipo secret (con All seleccionado para el servicio aplicado) antes de que se implemente la configuración que hace referencia a ella.

Purgar token de API purge-API-token

Los clientes pueden purgar la caché de CDN usando un token de API de purga declarado. El token se declara con la sintaxis siguiente. Consulte la sección Configuración común para obtener información sobre cómo implementarla.

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  experimental_authentication:
    authenticators:
       - name: purge-auth
         type: purge
         purgeKey1: ${{CDN_PURGEKEY_031224}}
         purgeKey2: ${{CDN_PURGEKEY_021225}}
    rules:
       - name: purge-auth-rule
         when: { reqProperty: tier, equals: "publish" }
         action:
           type: authenticate
           authenticator: purge-auth

La sintaxis incluye lo siguiente:

  • tipo, versión y metadatos.

  • nodo de datos que contiene un nodo experimental_authentication secundario (el prefijo experimental se quitará cuando se libere la característica).

  • En experimental_authentication, un nodo authenticators y un nodo rules, ambos son matrices.

  • Autenticadores: Permite declarar un tipo de token o credencial, que en este caso es una clave de depuración. Incluye las siguientes propiedades:

    • name: una cadena descriptiva.
    • type: debe ser purge.
    • purgeKey1 - su valor debe hacer referencia a un token secreto, que no debería almacenarse en Git, sino declararse como Variables de entorno de Cloud Manager de tipo secret.
    • En el campo Servicio aplicado, seleccione Todo. Se recomienda que el valor (por ejemplo, ${{CDN_PURGEKEY_031224}}) refleje el día en que se agregó.
    • purgeKey2 se usa para la rotación de secretos, que se describe en la sección rotación de secretos a continuación. Se debe declarar al menos uno de purgeKey1 y purgeKey2.
  • Reglas: le permite declarar cuál de los autenticadores debe utilizarse y si es para el nivel de publicación o vista previa. Incluye:

    • nombre: una cadena descriptiva
    • when: una condición que determina cuándo se debe evaluar la regla, según la sintaxis del artículo Reglas de filtro de tráfico. Normalmente, incluye una comparación del nivel actual (por ejemplo, … publicar).
    • action: debe especificar "authentication", con referencia al autenticador deseado.
NOTE
La clave de Edge debe configurarse como una variable de tipo Cloud Manager Environment Variable de tipo secret antes de que se implemente la configuración que hace referencia a ella.

Autenticación básica basic-auth

Proteja determinados recursos de contenido mostrando un cuadro de diálogo de autenticación básica que requiera un nombre de usuario y una contraseña. Esta función está diseñada principalmente para casos de uso de autenticación ligera, como la revisión del contenido por parte de las partes interesadas empresariales, en lugar de como una solución completa para los derechos de acceso del usuario final.

El usuario final verá aparecer un cuadro de diálogo de autenticación básico como el siguiente:

basicauth-dialog

La sintaxis se declara tal como se describe a continuación. Consulte la sección Configuración común a continuación para obtener información sobre cómo implementarla.

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev"]
data:
  experimental_authentication:
    authenticators:
       - name: my-basic-authenticator
         type: basic
         credentials:
           - user: johndoe
             password: ${{JOHN_DOE_PASSWORD}}
           - user: janedoe
             password: ${{JANE_DOE_PASSWORD}}
    rules:
       - name: basic-auth-rule
         when: { reqProperty: path, like: "/summercampaign" }
         action:
           type: authenticate
           authenticator: my-basic-authenticator

La sintaxis incluye lo siguiente:

  • tipo, versión y metadatos.

  • un nodo de datos que contenga un nodo experimental_authentication (el prefijo experimental se eliminará al lanzar la función).

  • En experimental_authentication, un nodo authenticators y un nodo rules, ambos son matrices.

  • Autenticadores: en este caso, declare un autenticador básico, que tiene la siguiente estructura:

    • nombre: una cadena descriptiva

    • tipo: debe ser basic

    • una matriz de credenciales, cada una de las cuales incluye los siguientes pares de nombre/valor, que los usuarios finales pueden introducir en el cuadro de diálogo autenticación básica:

      • user: nombre del usuario
      • password: su valor debe hacer referencia a un token secreto, que no debe almacenarse en Git, sino declararse como Variables de entorno de Cloud Manager de tipo secret (con All seleccionado como campo de servicio)
  • Rules: permite declarar cuál de los autenticadores se debe utilizar y qué recursos se deben proteger. Cada regla incluye:

    • nombre: una cadena descriptiva
    • when: una condición que determina cuándo se debe evaluar la regla, según la sintaxis del artículo Reglas de filtro de tráfico. Normalmente, incluye una comparación del nivel de publicación o rutas específicas.
    • action: debe especificar "authentication", con el autenticador deseado referenciado, que es basic-auth para este escenario
NOTE
La clave de Edge debe configurarse como una variable de tipo Cloud Manager Environment Variable de tipo secret antes de que se implemente la configuración que hace referencia a ella.

Configuración común common-setup

Todos los autenticadores se configuran de la siguiente manera:

  • En primer lugar, cree la siguiente estructura de carpetas y archivos en la carpeta de nivel superior del proyecto Git:
config/
     cdn.yaml
  • En segundo lugar, el archivo de configuración cdn.yaml debe contener los nodos descritos en los ejemplos siguientes. La propiedad kind debe establecerse en CDN y la versión debe establecerse en la versión de esquema, que actualmente es 1. El nodo de metadatos tiene una propiedad "envTypes", que indica en qué tipos de entorno (dev, stage, prod) se evaluará esta configuración.

  • Por último, cree una canalización de configuración de implementación de destino en Cloud Manager. Consulte configuración de canalizaciones de producción y configuración de canalizaciones que no son de producción.

Tenga en cuenta que:

  • Actualmente, los RDE no admiten la canalización de configuración.
  • Puede utilizar yq para validar localmente el formato YAML del archivo de configuración (por ejemplo, yq cdn.yaml).

Rotación de secretos rotating-secrets

Es recomendable cambiar las credenciales de vez en cuando. Esto se puede lograr como se muestra a continuación, utilizando el ejemplo de una clave perimetral, aunque se utiliza la misma estrategia para depurar claves.

  • Inicialmente solo se ha definido edgeKey1, en este caso se hace referencia a ${{CDN_EDGEKEY_052824}}, que como convención recomendada, refleja la fecha en que se creó.
experimental_authentication:
  authenticators:
    - name: edge-auth
      type: edge
      edgeKey1: ${{CDN_EDGEKEY_052824}}
  • Cuando sea el momento de girar la clave, cree un nuevo secreto de Cloud Manager, por ejemplo ${{CDN_EDGEKEY_041425}}.
  • En la configuración, haga referencia a él desde edgeKey2 e impleméntelo.
experimental_authentication:
  authenticators:
    - name: edge-auth
      type: edge
      edgeKey1: ${{CDN_EDGEKEY_052824}}
      edgeKey2: ${{CDN_EDGEKEY_041425}}
  • Una vez que esté seguro de que la clave perimetral antigua ya no se usa, elimínela eliminando edgeKey1 de la configuración.
experimental_authentication:
  authenticators:
    - name: edge-auth
      type: edge
      edgeKey2: ${{CDN_EDGEKEY_041425}}
  • Elimine la referencia secreta antigua (${{CDN_EDGEKEY_052824}}) de Cloud Manager e implemente.
  • Cuando esté listo para la siguiente rotación, siga el mismo procedimiento, pero esta vez agregará edgeKey1 a la configuración, haciendo referencia a un nuevo secreto de entorno de Cloud Manager llamado, por ejemplo, ${{CDN_EDGEKEY_031426}}.
experimental_authentication:
  authenticators:
    - name: edge-auth
      type: edge
      edgeKey2: ${{CDN_EDGEKEY_041425}}
      edgeKey1: ${{CDN_EDGEKEY_031426}}
recommendation-more-help
fbcff2a9-b6fe-4574-b04a-21e75df764ab