Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En esta página, se describe cómo exportar registros de Google Distributed Cloud (GDC) aislado a un sistema externo de administración de eventos e información de seguridad (SIEM). Esta integración permite el análisis de registros centralizado y la supervisión de seguridad mejorada.
La parte central de la exportación de registros implica la implementación de un recurso personalizado SIEMOrgForwarder.
Este recurso actúa como un archivo de configuración que especifica los detalles de la instancia externa del SIEM designada para recibir los registros. Al definir estos parámetros en el archivo SIEMOrgForwarder, los administradores pueden establecer un proceso de exportación de registros optimizado y seguro.
Antes de comenzar
Para obtener los permisos que necesitas para administrar los recursos personalizados de SIEMOrgForwarder, pídele al administrador de IAM de tu organización que te otorgue uno de los roles de la organización de exportación de SIEM asociados.
Según el nivel de acceso y los permisos que necesites, es posible que obtengas roles de creador, editor o visualizador para este recurso en el espacio de nombres de tu proyecto.
Para obtener más información, consulta Prepara los permisos de IAM.
Después de obtener los permisos necesarios, completa estos pasos antes de exportar los registros a un sistema SIEM externo:
Establece la conectividad: Asegúrate de que exista una conexión entre GDC y el destino SIEM externo. Si es necesario, colabora con el operador de infraestructura (IO) para establecer una conexión de vínculo ascendente a la red de tu cliente.
Configura las variables de entorno: Establece las siguientes variables de entorno para ejecutar los comandos de esta página:
Ruta de acceso del archivo kubeconfig:
exportKUBECONFIG=KUBECONFIG_PATH
Reemplaza KUBECONFIG_PATH por la ruta de acceso al archivo kubeconfig del servidor de la API de administración.
El espacio de nombres de tu proyecto:
exportPROJECT_NAMESPACE=PROJECT_NAMESPACE
Configura la exportación de registros
Exporta registros a un sistema SIEM externo:
Proporciona un token para conectar la pila de registros al sistema SIEM. Para realizar esta acción, debes crear un secreto en el espacio de nombres de tu proyecto para almacenar el token:
SECRET_FIELD: Es el nombre del campo en el que deseas almacenar el secreto.
TOKEN: Tu token.
Implementa el recurso personalizado SIEMOrgForwarder en el espacio de nombres de tu proyecto. Debes especificar el tipo de registro eligiendo entre registros de auditoría o registros operativos. Para configurar la exportación de registros para ambos tipos, debes implementar un recurso SIEMOrgForwarder para cada tipo.
En el siguiente ejemplo, se muestra cómo aplicar una configuración a un recurso personalizado SIEMOrgForwarder:
SIEM_ORG_FORWARDER: Es el nombre del archivo de definición de SIEMOrgForwarder.
LOG_TYPE: Es el tipo de registro que exportas. Los valores aceptados son audit y operational.
SIEM_HOST: Es el nombre del host del SIEM.
SECRET_NAME: Es el nombre de tu Secret.
SECRET_FIELD: Es el nombre del campo en el que almacenaste el secreto.
TLS: Es el estado de la seguridad de la capa de transporte (TLS). Los valores aceptados son "On" y "Off".
NET_CONNECT_TIMEOUT: Es el tiempo máximo en segundos que se espera para que se establezca una conexión. Por ejemplo, un valor de 180 significa esperar 180 segundos.
Verifica el estado del recurso personalizado SIEMOrgForwarder implementado:
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-04 (UTC)"],[[["\u003cp\u003eThis page guides you through exporting logs from Google Distributed Cloud (GDC) air-gapped to an external Security Information and Event Management (SIEM) system for centralized log analysis and security monitoring.\u003c/p\u003e\n"],["\u003cp\u003eThe core mechanism for log export is the \u003ccode\u003eSIEMOrgForwarder\u003c/code\u003e custom resource, which acts as a configuration file specifying details of the external SIEM instance.\u003c/p\u003e\n"],["\u003cp\u003eBefore exporting logs, you must obtain the necessary SIEM Export Org roles, establish network connectivity between GDC and the external SIEM, and set required environment variables.\u003c/p\u003e\n"],["\u003cp\u003eExporting logs requires creating a secret in your project namespace to store the token for connecting the logging stack to the SIEM system, and deploying a \u003ccode\u003eSIEMOrgForwarder\u003c/code\u003e resource for each log type (audit or operational).\u003c/p\u003e\n"],["\u003cp\u003eThe logging stack will only retry the connection to the SIEM solution five times by default, after which audit logs will no longer be sent.\u003c/p\u003e\n"]]],[],null,["# Export logs to a SIEM system\n\nThis page describes how to export logs from Google Distributed Cloud (GDC) air-gapped to an\nexternal Security Information and Event Management (SIEM) system. This\nintegration allows for centralized log analysis and enhanced security\nmonitoring.\n\nThe core of log export involves deploying a `SIEMOrgForwarder` custom resource.\nThis resource acts as a configuration file, specifying the details of the\nexternal SIEM instance designated to receive the logs. By defining these\nparameters within the `SIEMOrgForwarder` file, administrators can establish a\nstreamlined and secure log export pipeline.\n\nBefore you begin\n----------------\n\nTo get the permissions that you need to manage `SIEMOrgForwarder` custom\nresources, ask your Organization IAM Admin to grant you one of the associated\nSIEM Export Org roles.\n\nDepending on the level of access and permissions you need, you might obtain\ncreator, editor, or viewer roles for this resource in your project namespace.\nFor more information, see [Prepare IAM permissions](/distributed-cloud/hosted/docs/latest/gdch/platform/pa-user/obs-iam-permissions).\n\nAfter obtaining the necessary permissions, complete these steps prior to\nexporting logs to an external SIEM system:\n\n1. **Establish connectivity**: Ensure a connection exists between\n GDC and the external SIEM destination. If needed,\n collaborate with the Infrastructure Operator (IO) to establish an uplink\n connection to your customer network.\n\n2. **Set environment variables**: Set the following environment variables to\n run the commands from this page:\n\n - The path of the kubeconfig file:\n\n export KUBECONFIG=\u003cvar translate=\"no\"\u003eKUBECONFIG_PATH\u003c/var\u003e\n\n Replace \u003cvar translate=\"no\"\u003eKUBECONFIG_PATH\u003c/var\u003e with the path to the\n kubeconfig file for the Management API server.\n - Your project namespace:\n\n export PROJECT_NAMESPACE=\u003cvar translate=\"no\"\u003ePROJECT_NAMESPACE\u003c/var\u003e\n\nConfigure log export\n--------------------\n\n| **Important:** The logging stack limits the number of retries to establish a connection with the SIEM solution and send an audit log. The Infrastructure Operator can manually configure the exact number of retries, but the default is set to *five*. If the connection fails after the specified retries, the logging stack doesn't send audit logs to the SIEM solution.\n\nExport logs to an external SIEM system:\n\n1. Provide a token to connect the logging stack to the SIEM system. To perform\n this action, you must create a secret in your project namespace to store the\n token:\n\n cat \u003c\u003cEOF | kubectl --kubeconfig=${KUBECONFIG} apply -f -\n apiVersion: v1\n kind: Secret\n metadata:\n name: \u003cvar translate=\"no\"\u003eSECRET_NAME\u003c/var\u003e\n namespace: ${PROJECT_NAMESPACE}\n type: Opaque\n stringData:\n \u003cvar translate=\"no\"\u003eSECRET_FIELD\u003c/var\u003e: \u003cvar translate=\"no\"\u003eTOKEN\u003c/var\u003e\n EOF\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eSECRET_NAME\u003c/var\u003e: the name of your secret.\n - \u003cvar translate=\"no\"\u003eSECRET_FIELD\u003c/var\u003e: the name of the field where you want to store the secret.\n - \u003cvar translate=\"no\"\u003eTOKEN\u003c/var\u003e: your token.\n\n | **Note:** Consider using separate tokens for audit and operational logs, deploying two secrets accordingly. You must reference the corresponding secret name in the `SIEMOrgForwarder` custom resource.\n2. Deploy the `SIEMOrgForwarder` custom resource in your project namespace. You\n must specify the log type by choosing between audit or operational logs. To\n configure the log export for both log types, you must deploy a\n `SIEMOrgForwarder` resource for each type.\n\n | **Important:** The `SIEMOrgForwarder` custom resource must be in the same namespace as the `Secret` you created in the previous step.\n\n The following example shows how to apply a configuration to a\n `SIEMOrgForwarder` custom resource: \n\n cat \u003c\u003cEOF | kubectl --kubeconfig=${KUBECONFIG} apply -f -\n apiVersion: logging.gdc.goog/v1\n kind: SIEMOrgForwarder\n metadata:\n name: \u003cvar translate=\"no\"\u003eSIEM_ORG_FORWARDER\u003c/var\u003e\n namespace: ${PROJECT_NAMESPACE}\n spec:\n source: \u003cvar translate=\"no\"\u003eLOG_TYPE\u003c/var\u003e\n splunkOutputs:\n - host: \u003cvar translate=\"no\"\u003eSIEM_HOST\u003c/var\u003e\n token:\n name: \u003cvar translate=\"no\"\u003eSECRET_NAME\u003c/var\u003e\n field: \u003cvar translate=\"no\"\u003eSECRET_FIELD\u003c/var\u003e\n tls: \"\u003cvar translate=\"no\"\u003eTLS\u003c/var\u003e\"\n netConnectTimeout: \u003cvar translate=\"no\"\u003eNET_CONNECT_TIMEOUT\u003c/var\u003e\n EOF\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eSIEM_ORG_FORWARDER\u003c/var\u003e: the name of the `SIEMOrgForwarder` definition file.\n - \u003cvar translate=\"no\"\u003eLOG_TYPE\u003c/var\u003e: the log type you are exporting. Accepted values are `audit` and `operational`.\n - \u003cvar translate=\"no\"\u003eSIEM_HOST\u003c/var\u003e: the name of the SIEM host.\n - \u003cvar translate=\"no\"\u003eSECRET_NAME\u003c/var\u003e: the name of your secret.\n - \u003cvar translate=\"no\"\u003eSECRET_FIELD\u003c/var\u003e: the name of the field where you stored the secret.\n - \u003cvar translate=\"no\"\u003eTLS\u003c/var\u003e: the status of the Transport Layer Security (TLS). Accepted values are `\"On\"` and `\"Off\"`.\n - \u003cvar translate=\"no\"\u003eNET_CONNECT_TIMEOUT\u003c/var\u003e: the maximum time in seconds to wait for a connection to be established. For example, a value of `180` means to wait 180 seconds.\n3. Verify the status of the deployed `SIEMOrgForwarder` custom resource:\n\n kubectl --kubeconfig=${KUBECONFIG} describe siemorgforwarder/\u003cvar translate=\"no\"\u003eSIEM_ORG_FORWARDER\u003c/var\u003e \\\n -n ${PROJECT_NAMESPACE}\n\n According to the log type, check for the following status:\n - **Audit logs** : Check the `AuditLoggingReady` status.\n - **Operational logs** : Check the `OperationalLoggingReady` status.\n\n | **Note:** It might take a few minutes for changes to propagate and the status to update."]]