[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["わかりにくい","hardToUnderstand","thumb-down"],["情報またはサンプルコードが不正確","incorrectInformationOrSampleCode","thumb-down"],["必要な情報 / サンプルがない","missingTheInformationSamplesINeed","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 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."]]