Agente de OpenSearch

El agente de OpenSearch es un servicio junto al clúster. Mantiene el control de acceso propio del plug-in de seguridad al día con las políticas firmadas de un servicio de datos opensearch: un rol por usuario que contiene exactamente lo que las políticas le dan, asignado solo a ese usuario, con seguridad a nivel de campo, campos enmascarados y seguridad a nivel de documento. OpenSearch comprueba entonces cada petición por sí mismo, y el agente nunca se interpone entre los clientes y el clúster. La distribución lo incluye como JAR ejecutable, agents/opensearch/grantforge-agent-opensearch-<version>.jar, que requiere Java 17 o posterior.

Las pruebas de integración con Testcontainers del repositorio ejecutan el agente, y el JAR tal como se distribuye, contra OpenSearch 2.19, 3.3, 3.6 y 3.9 con el plug-in de seguridad. Esto no certifica todas las demás versiones; el agente rechaza clústeres anteriores a 2.19 y clústeres sin plug-in de seguridad. Para el plug-in de servicio, consulte OpenSearch.

Funcionamiento

• Un rol por usuario contiene lo que da GrantForge. Para cada usuario al que las políticas dan algo, el agente mantiene un rol con su nombre, grantforge_alice para alice, asignado solo a ese usuario. Su descripción lo marca como del agente, y el agente no toma ningún rol sin esa marca por uno propio, de modo que no cambia ningún otro rol ni asignación.
• Los patrones de índice siguen siendo patrones. Un patrón de índice de una política, como logs-*, se concede como patrón allí donde todas las políticas deciden igual en toda su extensión: toda política de cualquier tipo cuyos índices se solapan con el patrón lo cubre por completo. El agente lo decide con exactitud, con autómatas finitos de los patrones. Los índices creados después, como los registros de mañana, son entonces accesibles al instante, también cuando el primer documento escrito los crea. Donde una política decide otra cosa dentro de un patrón, como una denegación de logs-secret dentro de logs-*, el agente concede por nombre cada índice y flujo de datos que tiene el clúster, y los nuevos en la siguiente sincronización.
• Seguridad a nivel de campo solo donde algo por debajo se decide de otro modo. Un índice que el usuario puede leer entero, sin política que pueda quitarle un campo, se lee sin seguridad a nivel de campo, de modo que los campos añadidos después se leen al instante. Si no, el usuario lee los campos que permite una política, de los que tienen sus documentos y los que nombran las políticas; los multicampos como name.keyword siguen a su campo.
• Máscaras y filtros de filas son los del plug-in de seguridad. Una máscara se convierte en un campo enmascarado de la entrada, y un filtro de filas en su consulta de seguridad a nivel de documento. La API validate de OpenSearch comprueba cada consulta antes de concederla; una consulta que OpenSearch no ejecutaría no muestra ningún documento al usuario, y se registra. Una máscara que el plug-in de seguridad no conoce oculta el campo en su lugar.
• Una entrada por conjunto de permisos. Los índices y patrones con los mismos permisos comparten una entrada; las entradas nunca se solapan, ya que el plug-in de seguridad combina la seguridad a nivel de campo y de documento de las entradas que se solapan.
• Las operaciones compuestas del clúster vienen con la lectura y la escritura. La lectura trae cluster_composite_ops_ro, para multi-search, multi-get y desplazamiento, y la escritura cluster_composite_ops, para bulk.
• Los cambios son un parche. El agente escribe sus roles y asignaciones como parches JSON, que el plug-in de seguridad aplica de una vez en todo el clúster: los roles antes de las asignaciones que los nombran, las asignaciones antes de los roles que nombran y que se eliminan. Un parche que el plug-in de seguridad rechaza se aplica cambio a cambio, de modo que un rol defectuoso falla solo.
• Las políticas del momento presente. Cada sincronización planifica según las políticas tal como se aplican en ese momento, de modo que los periodos de validez empiezan y terminan a tiempo.
• Los roles de backend son grupos. Una política para un grupo se aplica a los usuarios internos que tienen un rol de backend con ese nombre, junto con los grupos en los que GrantForge pone a los usuarios.
• Los cambios hechos a mano se deshacen. El agente compara en cada sincronización sus roles y asignaciones con lo que guarda el plug-in de seguridad; lo que difiere se vuelve a escribir. Cuando nada ha cambiado, el agente no envía nada.
• Se informa de los roles fuera de GrantForge. OpenSearch concede lo que da cualquiera de los roles de un usuario, por lo que el agente no puede quitar lo que da otro rol asignado al usuario. Avisa una vez de cada rol así que da lo que deniega una política, nombrando el rol, el usuario, el acceso, el índice y la política, y de los usuarios asignados a all_access, a los que ningún rol limita.
• Los accesos vienen del registro de auditoría. El agente lee el registro de auditoría del plug-in de seguridad de los índices donde lo escribe, security-auditlog-*: lo que rechazó, como MISSING_PRIVILEGES, y lo que permitió, como GRANTED_PRIVILEGES cuando la configuración de auditoría los registra. Cada evento nombra al usuario, el tipo de acceso, cada índice o flujo de datos alcanzado, o el clúster, y dice si lo decidió GrantForge o lo permitió un rol fuera de GrantForge.

Despliegue

1. Añada un servicio de datos opensearch y configure sus políticas. Abra Permisos sobre los datos → Agentes, seleccione el servicio y emita un token de agente. Solo se muestra una vez; guárdelo en un archivo que solo pueda leer la cuenta del agente.

2. Dé al agente un usuario que pueda cambiar la configuración del plug-in de seguridad: un usuario asignado a all_access mientras plugins.security.restapi.roles_enabled lo incluya, o el certificado de administración que nombra plugins.security.authcz.admin_dn. Las pruebas ejecutan el agente como el admin de la configuración de demostración, y con su certificado de administración.

3. Para informar de los accesos, mantenga el registro de auditoría en el clúster (plugins.security.audit.type: internal_opensearch). Para lo que OpenSearch permitió, quite además GRANTED_PRIVILEGES de las categorías desactivadas de la configuración de auditoría; las denegaciones se registran de forma predeterminada.

4. Escriba el archivo de ajustes, sustituyendo las direcciones, rutas y nombres de ejemplo:

   grantforge.server.url=https://grantforge.example.com
   grantforge.token.file=/etc/grantforge/opensearch-agent.token
   grantforge.instance=opensearch-agent-1
   grantforge.cache.dir=/var/lib/grantforge/opensearch-agent
   grantforge.opensearch.hosts=https://opensearch1.internal:9200,https://opensearch2.internal:9200
   grantforge.opensearch.user=grantforge
   grantforge.opensearch.password.file=/etc/grantforge/opensearch-agent.password
   grantforge.opensearch.tls.ca=/etc/grantforge/opensearch-ca.pem

   Estas rutas están en la máquina del agente, y el directorio de caché debe admitir escritura. Los archivos de contraseña se leen como UTF-8 y se recortan.

5. Inicie el agente, por ejemplo como servicio de systemd:

   java -jar agents/opensearch/grantforge-agent-opensearch-<version>.jar /etc/grantforge/opensearch-agent.properties

   Sustituya <version> por la versión de la distribución. Los ajustes indicados como java -Dgrantforge.…=… -jar … prevalecen sobre el archivo. El agente se detiene limpiamente con SIGTERM y envía o guarda en cola los eventos pendientes; OpenSearch conserva lo que se le dio.

6. Pasar los roles existentes a políticas: los roles asignados a usuarios fuera de GrantForge siguen aplicándose junto a los del agente. Cree las políticas correspondientes y después elimine esas asignaciones; los avisos del agente nombran los roles que dan lo que deniega una política.

Usuarios, grupos y roles

Las políticas nombran a los usuarios de OpenSearch tal como los conoce el plug-in de seguridad. El agente mantiene roles para los usuarios internos, para los usuarios que nombran las políticas, que pueden iniciar sesión mediante un directorio como LDAP o SAML, y para los usuarios para los que ya mantenía roles; los usuarios reservados y ocultos del plug-in de seguridad, como kibanaserver, se dejan en paz. Los grupos son los roles de backend de un usuario interno junto con los grupos en los que GrantForge pone al usuario; el agente no conoce los roles de backend que da un directorio al iniciar sesión, así que dé a esos usuarios sus grupos en GrantForge. Los roles son los que GrantForge da al usuario.

Decisiones y limitaciones

• Sin instantánea el agente no cambia nada. Un servicio que no está en uso, o un token vinculado a un servicio cuyo tipo no es opensearch, no concede nada: el agente elimina sus roles y asignaciones, y se aplican los roles propios del plug-in de seguridad.
• Mientras el agente no se ejecuta, OpenSearch conserva lo último que se le dio; los cambios de políticas lo esperan. Un cambio llega a OpenSearch dentro del intervalo de actualización y el de sincronización.
• Los índices concedidos por nombre, y no mediante un patrón, reciben sus permisos en la siguiente sincronización.
• Los alias alcanzan los índices que agrupan: buscar en un alias requiere permisos sobre cada índice que contiene, por eso las políticas nombran índices y flujos de datos, no alias.
• Un filtro de filas solo puede comprobar campos que el usuario puede leer, y una máscara se aplica a valores de campos text y keyword.
• Los índices cuyo nombre empieza por un punto solo se alcanzan mediante patrones de política que empiezan por un punto.
• El agente no gestiona los tenants del plug-in de seguridad para OpenSearch Dashboards.

Guías relacionadas

• OpenSearch
• Servicios de datos, políticas y agentes