Cómo configurar reglas de acceso en Authelia paso a paso

Si ya tienes Authelia funcionando y protegiendo tus aplicaciones, el siguiente paso consiste en decidir quién puede entrar, desde dónde y con qué nivel de autenticación. No todos los usuarios necesitan acceder a los mismos servicios ni todas las rutas presentan el mismo riesgo.

Las reglas de acceso de Authelia permiten aplicar políticas diferentes según el dominio, la ruta solicitada, el usuario, sus grupos, la dirección IP de origen o incluso el método HTTP. Así puedes exigir dos factores para un panel administrativo, permitir un acceso más sencillo desde una VPN y bloquear cualquier petición que no hayas autorizado expresamente.

Qué controlan las reglas de acceso de Authelia

Las reglas se definen dentro de la sección access_control del archivo de configuración. Cuando el proxy inverso consulta a Authelia, el sistema analiza los datos de la petición y determina qué política debe aplicarse antes de permitir o rechazar el acceso.

Una regla puede utilizar los siguientes criterios:

• Dominio: identifica la aplicación o los subdominios afectados.
• Recurso: limita la regla a una ruta o conjunto de rutas.
• Sujeto: aplica la política a usuarios o grupos determinados.
• Red: comprueba la dirección IP desde la que llega la petición.
• Método: diferencia entre peticiones GET, POST, PUT, DELETE u otras.
• Consulta: permite evaluar determinados parámetros incluidos en la URL.

Estas políticas solo afectan a las peticiones que pasan por el mecanismo de autorización del proxy. Si la aplicación mantiene un puerto accesible directamente, un visitante podría evitar Authelia entrando mediante la IP y ese puerto.

Cómo evalúa Authelia las reglas de acceso

Authelia examina las reglas secuencialmente, de arriba abajo. En cuanto encuentra la primera donde coinciden todos los criterios, aplica su política y deja de revisar las siguientes. Si ninguna coincide, utiliza el valor de default_policy.

Esto significa que las reglas más específicas deben aparecer antes que las generales. Por ejemplo, si quieres dejar público un endpoint de comprobación, proteger el panel con 2FA y aplicar una contraseña al resto, puedes utilizar este orden:

access_control:
  default_policy: 'deny'
  rules:
    - domain: 'estado.example.com'
      resources:
        - '^/api/health([/?].*)?$'
      policy: 'bypass'

    - domain: 'estado.example.com'
      subject:
        - 'group:admins'
      policy: 'two_factor'

    - domain: 'estado.example.com'
      policy: 'one_factor'

La excepción para /api/health debe aparecer primero. Si la regla general del dominio estuviera delante, Authelia la aplicaría inmediatamente y nunca alcanzaría la excepción.

Qué política de acceso debes utilizar

Authelia dispone de cuatro políticas principales. Cada una determina el nivel mínimo necesario para completar la petición:

• deny: bloquea completamente el acceso al recurso.
• bypass: permite acceder sin autenticarse en Authelia.
• one_factor: exige como mínimo usuario y contraseña.
• two_factor: obliga a completar también un segundo factor compatible.

La configuración más segura consiste en utilizar deny como política predeterminada y permitir únicamente lo necesario mediante reglas explícitas. De esta manera, una aplicación nueva no quedará expuesta accidentalmente por no haber creado todavía su regla.

access_control:
  default_policy: 'deny'
  rules:
    - domain: 'documentos.example.com'
      policy: 'one_factor'

    - domain: 'panel.example.com'
      policy: 'two_factor'

Conviene utilizar bypass con mucha precaución, ya que elimina la autenticación para cualquier petición que coincida. Además, no puede combinarse con el criterio subject, porque Authelia necesita autenticar primero al visitante para averiguar su usuario y sus grupos.

Cómo crear reglas por dominio y subdominio

El criterio domain permite indicar un dominio exacto o una lista de dominios. También admite comodines para aplicar una misma política a varios subdominios.

access_control:
  default_policy: 'deny'
  rules:
    - domain:
        - 'grafana.example.com'
        - 'portainer.example.com'
      policy: 'two_factor'

    - domain: '*.interno.example.com'
      policy: 'one_factor'

El comodín *.interno.example.com afectará a los subdominios situados bajo esa dirección. Debe escribirse entre comillas para evitar que YAML interprete el asterisco de otra manera.

Los dominios utilizados en las reglas deben estar cubiertos por uno de los dominios definidos en session.cookies. Si no lo están, Authelia denegará automáticamente la petición, aunque la regla parezca correcta.

Cómo limitar el acceso por usuarios y grupos

El criterio subject permite aplicar una política solamente a determinados usuarios o grupos. Los valores deben comenzar con user: o group:.

access_control:
  default_policy: 'deny'
  rules:
    - domain: 'panel.example.com'
      subject:
        - 'group:admins'
      policy: 'two_factor'

    - domain: 'documentos.example.com'
      subject:
        - 'user:ana'
        - 'group:editores'
      policy: 'one_factor'

En el segundo ejemplo podrán entrar la usuaria ana o cualquier integrante del grupo editores. Los elementos situados en el nivel principal de la lista funcionan como alternativas.

También puedes exigir que una persona pertenezca simultáneamente a varios grupos:

subject:
  - 'user:ana'
  - ['group:admins', 'group:infraestructura']

Esta condición coincide con la usuaria ana o con cualquier persona que pertenezca a los grupos admins e infraestructura al mismo tiempo.

Cómo proteger rutas concretas con Authelia

El criterio resources utiliza expresiones regulares para aplicar políticas distintas dentro de un mismo dominio. Esto permite exigir 2FA para una zona administrativa sin imponerlo necesariamente al resto de la aplicación.

access_control:
  default_policy: 'deny'
  rules:
    - domain: 'app.example.com'
      resources:
        - '^/admin([/?].*)?$'
      policy: 'two_factor'

    - domain: 'app.example.com'
      policy: 'one_factor'

La expresión protege /admin, sus subrutas y las variantes que incluyan parámetros. Como la regla administrativa es más específica, debe colocarse antes que la regla general.

Las expresiones deben escribirse siempre entre comillas. Una barra, un carácter especial o un escape incorrecto puede impedir que Authelia arranque o hacer que la regla abarque más rutas de las previstas.

Cómo aplicar reglas según la red de origen

Las redes pueden declararse mediante direcciones individuales, rangos CIDR o grupos reutilizables. Esto resulta útil para pedir un solo factor desde la red local o una VPN y exigir dos factores cuando la conexión procede de Internet.

definitions:
  network:
    red_local:
      - '192.168.1.0/24'
    vpn:
      - '10.8.0.0/24'

access_control:
  default_policy: 'deny'
  rules:
    - domain: 'panel.example.com'
      networks:
        - 'red_local'
        - 'vpn'
      policy: 'one_factor'

    - domain: 'panel.example.com'
      policy: 'two_factor'

Authelia necesita recibir correctamente la IP original del visitante. Por tanto, el proxy debe enviar las cabeceras correspondientes y solo deben declararse como confiables los proxies que realmente controles. Confiar en cabeceras procedentes de cualquier origen permitiría falsificar la dirección IP y eludir una regla basada en la red.

Aunque técnicamente puedes aplicar bypass</code dentro de la LAN, mantener al menos one_factor suele ser una opción más prudente para paneles sensibles.

Cuándo utilizar reglas por método HTTP

El criterio methods permite distinguir entre solicitudes GET, POST, PUT, PATCH, DELETE, OPTIONS y otros métodos reconocidos. Un caso habitual consiste en permitir sin autenticación las peticiones CORS de comprobación previa:

access_control:
  default_policy: 'deny'
  rules:
    - domain: 'api.example.com'
      methods:
        - 'OPTIONS'
      policy: 'bypass'

    - domain: 'api.example.com'
      policy: 'two_factor'

No conviene utilizar este criterio para subir el nivel de autenticación durante el envío de un formulario. Authelia no puede conservar el cuerpo de una solicitud al redirigir al usuario, por lo que una petición POST podría perder los datos enviados.

Cuando una aplicación necesite permisos distintos para leer y modificar información, suele ser mejor gestionar esa autorización dentro de la propia aplicación o mediante sus roles.

Cómo comprobar qué regla aplicará Authelia

Antes de reiniciar el servicio, puedes validar la sintaxis del archivo desde el contenedor:

docker exec authelia authelia config validate \
  --config /config/configuration.yml

El comando access-control check-policy permite simular una petición y comprobar qué regla coincidirá:

docker exec authelia authelia access-control check-policy \
  --config /config/configuration.yml \
  --url https://panel.example.com/admin \
  --username ana \
  --groups admins,infraestructura \
  --ip 192.168.1.50 \
  --method GET \
  --verbose

La salida identifica la primera coincidencia completa y muestra qué criterios acertaron o fallaron. Es recomendable repetir la prueba con diferentes usuarios, grupos, rutas, redes y métodos antes de aplicar las reglas en producción.

Errores frecuentes al configurar reglas de acceso

Una regla general aparece antes que la excepción

Authelia se detiene en la primera coincidencia completa. Coloca primero las reglas más específicas y deja las generales para el final.

Se combina bypass con un usuario o grupo

Una regla bypass no puede utilizar subject. Para conocer la identidad del visitante, Authelia debe exigir como mínimo one_factor.

El dominio no está cubierto por la cookie de sesión

Comprueba que el dominio de la aplicación coincida con uno de los configurados en session.cookies o sea un subdominio válido.

La expresión regular coincide con demasiadas rutas

Ancla los patrones con ^ y $ cuando corresponda y comprueba cada URL mediante check-policy antes de reiniciar.

Authelia recibe una dirección IP incorrecta

Revisa las cabeceras reenviadas por el proxy y su configuración de proxies confiables. De lo contrario, las reglas basadas en networks no funcionarán correctamente.

La aplicación continúa accesible mediante su puerto

Las reglas no pueden proteger una conexión que evita el proxy. Cierra la publicación directa del puerto y utiliza una red interna entre los contenedores.

La misma sección aparece en varios archivos

No declares access_control en varios archivos esperando que Authelia combine automáticamente las reglas. Centraliza la sección en un único archivo de configuración.

Un formulario pierde los datos al exigir 2FA

Una redirección durante una petición POST puede descartar el contenido enviado. Evita utilizar reglas por método para implementar permisos internos de la aplicación.

Configurar correctamente las reglas de acceso de Authelia permite aplicar el principio de mínimos privilegios sin administrar un sistema de autenticación independiente en cada servicio. La clave consiste en establecer deny como política predeterminada, ordenar las excepciones desde la más específica hasta la más general y validar cada escenario antes de exponerlo a usuarios reales.