mirror of
https://github.com/andwati/zitadel.git
synced 2026-10-24 16:22:16 +00:00
## Todos for release - [x] Configure Env in docs project on vercel - [x] Configure Root Path in the docs project on vercel - [ ] Remove old CSP https://github.com/zitadel/website/pull/1592 ## What we did This pull request migrates the project documentation from the old `docs/` directory to the new `apps/docs/` directory, introduces a new documentation system built with Next.js and Fumadocs, and updates all relevant references, configuration files, and documentation to reflect this change. It also adds new configuration and ignore files for the new documentation app, updates CI and linting to exclude the new docs from certain checks, and revises the contributing guidelines accordingly. **Documentation System Migration and New Docs App** * Migrated all documentation from `docs/` to `apps/docs/`, and updated all references in `README.md`, `CONTRIBUTING.md`, and other files to point to the new location. [[1]](diffhunk://#diff-eca12c0a30e25b4b46522ebf89465a03ba72a03f540796c979137931d8f92055L585-L640) [[2]](diffhunk://#diff-eca12c0a30e25b4b46522ebf89465a03ba72a03f540796c979137931d8f92055L660-R607) [[3]](diffhunk://#diff-eca12c0a30e25b4b46522ebf89465a03ba72a03f540796c979137931d8f92055L740-R687) [[4]](diffhunk://#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5L2-R3) [[5]](diffhunk://#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5L30-R30) * Added a new Next.js/Fumadocs-based documentation app under `apps/docs/`, including core app files, layouts, routing, search API, and a comprehensive `README.md` with development and contribution instructions. [[1]](diffhunk://#diff-5a1b07344a2c1b4d3f37b23ff1388b62cd9f57dea3c1cd23d8a0412b7602b132R1-R74) [[2]](diffhunk://#diff-462b9ad1eabbb7d1c29bb9c36e4931eb180fd7190900e6d2babf8f4d66ad1c28R1-R39) [[3]](diffhunk://#diff-e16ae25660ded787b10ac35dea96d5ecaacf895dae0afc8a9bd4382dc79a8c87R1-R7) [apps/docs/app/[[...slug]]/layout.tsxR1-R81](diffhunk://#diff-59e08acde4e805b7aeccef1dcf98f1d71dfc550777e6b9402085cee0e9fa4e0aR1-R81), [apps/docs/app/[[...slug]]/page.tsxR1-R79](diffhunk://#diff-e5df3f80d0fa01e12d63d81f29c57a9d14e846c78fd3beabb2ef768e38fd9580R1-R79), [[4]](diffhunk://#diff-389b34918e040cacaa87cd7201ffa462cc2b0b716736f537e3d3c660ac69353bR1-R7) [[5]](diffhunk://#diff-d3b03416d1c457b19f1c27b26f2db741412df841b875c26ccadc36e4522247f4R1-R29) [[6]](diffhunk://#diff-c8fb8339570a5305809be7c618e14705fd86390dc278e6ce8ba224a7bc8b0c3cR1-R25) **Configuration and Tooling Updates** * Updated `.github/workflows/codeql.yml`, `.golangci.yaml`, and `.github/dependabot.yml` to properly handle the new docs app: excluded `apps/docs` from certain checks, added npm dependency updates for the docs app, and excluded generated content. [[1]](diffhunk://#diff-12783128521e452af0cfac94b99b8d250413c516ec71fe6d97dbea666ff7ba27L8-R14) [[2]](diffhunk://#diff-9917ddc9f1c3304218f7269265b746d997c5c0615478177b5fceecd33ef47cb5R5-R6) [[3]](diffhunk://#diff-9917ddc9f1c3304218f7269265b746d997c5c0615478177b5fceecd33ef47cb5R126-R129) [[4]](diffhunk://#diff-dd4fbda47e51f1e35defb9275a9cd9c212ecde0b870cba89ddaaae65c5f3cd28R89-R106) * Updated `.devcontainer/devcontainer.json` to use the latest Go 1.25.3 version for consistency. **Licensing and Miscellaneous** * Added `apps/docs/` to the list of licensed directories in `LICENSING.md`. These changes ensure the documentation is now maintained in a modern, scalable system and all project tooling is updated to support the new structure. --------- Co-authored-by: Federico Coppede <[email protected]>
81 lines
5.6 KiB
Plaintext
81 lines
5.6 KiB
Plaintext
---
|
|
title: Streaming audit logs to external systems (SIEM/SOC)
|
|
sidebar_label: Audit Logs (SIEM / SOC)
|
|
---
|
|
|
|
This document details integrating ZITADEL with external systems for streaming events and audit logs.
|
|
This functionality allows you to centralize ZITADEL activity data alongside other security and operational information, facilitating comprehensive monitoring, analysis, and compliance reporting.
|
|
|
|
Integrating ZITADEL with external systems offers several advantages:
|
|
- **Centralized Monitoring**: Streamlining ZITADEL events into a single platform alongside data from various sources enables a consolidated view of your security posture. This comprehensive view simplifies threat detection, investigation, and incident response.
|
|
- **Enhanced Security Analytics**: External systems, such as Security Information and Event Management (SIEM) solutions, can leverage ZITADEL events to identify suspicious activities, potential security breaches, and user access anomalies.
|
|
- **Compliance Reporting**: ZITADEL events can be used to generate detailed audit trails, fulfilling regulatory compliance requirements for data access and user activity.
|
|
|
|
By integrating ZITADEL with external systems, you gain valuable insights into user behavior, system activity, and potential security threats, ultimately strengthening your overall security posture and regulatory compliance.
|
|
|
|
ZITADEL provides different solutions how to send events to external systems, the solution you choose might differ depending on your use case, your database and your environment (ZITADEL Cloud, Self-hosting).
|
|
|
|
The following table shows the available integration patterns for streaming audit logs to external systems.
|
|
|
|
| | Description | Self-hosting | ZITADEL Cloud |
|
|
|-------------------------------------|----------------------------------------------------------------------------------------------------------------|-------------|---------------|
|
|
| Events-API | Pulling events of all ZITADEL resources such as Users, Projects, Apps, etc. (Events = Change Log of Resources) | ✅ | ✅ |
|
|
| ZITADEL Actions Log to Stdout | Custom log to messages possible on predefined triggers during login / register Flow | ✅ | ❌ |
|
|
| ZITADEL Actions trigger API/Webhook | Custom API/Webhook request on predefined triggers during login / register | ✅ | ✅ |
|
|
|
|
### Events API
|
|
|
|
The ZITADEL Event API empowers you to proactively pull audit logs for comprehensive security and compliance monitoring, regardless of your environment (cloud or self-hosted).
|
|
This API offers granular control through various filters, enabling you to:
|
|
- **Specify Event Types**: Focus on specific events of interest, such as user token created, password changed, or project added.
|
|
- **Target Aggregates**: Narrow down the data scope by filtering for events related to particular organizations, projects, or users.
|
|
- **Define Time Frames**: Retrieve audit logs for precise time periods, allowing you to schedule data retrieval at desired intervals (e.g., hourly) and analyze activity within specific windows.
|
|
|
|
You can find a comprehensive guide on how to use the events API for different use cases here: [Get Events from ZITADEL](/guides/integrate/zitadel-apis/event-api)
|
|
|
|
## ZITADEL Actions
|
|
|
|
ZITADEL [Actions](/concepts/features/actions) offer a powerful mechanism for extending the platform's capabilities and integrating with external systems tailored to your specific requirements.
|
|
Actions are essentially custom JavaScript snippets that execute at predefined triggers during the registration or login flow of a user.
|
|
|
|
In the future ZITADEL Actions will be extended to allow to not only define them during the login and register flow, but also on each API Request, Event or Predefined Functions.
|
|
|
|
### Log to stdout
|
|
|
|
With the [log module](/apis/actions/modules#log) you can log any custom message to stdout.
|
|
Those logs in stdout can be collected by your external system.
|
|
|
|
Example Use Case:
|
|
In my external system for example Splunk I want to be able to get an information each time a user has authenticated.
|
|
|
|
1. Define an action that logs successful and failed login to your stdout.
|
|
Make sure the name of the action is the same as of the function in the script.
|
|
```ts reference
|
|
https://github.com/zitadel/actions/blob/main/examples/post_auth_log.js
|
|
```
|
|
2. Add the action to the following Flows and Triggers
|
|
- Flow: Internal Authentication - Trigger: Post Authentication
|
|
- Flow: External Authentication - Trigger: Post Authentication
|
|
3. Authenticate User
|
|
4. Collect Data from stdout
|
|
|
|
### Webhook/API request
|
|
|
|
The [http module](/apis/actions/modules#http) allows you to make a request to a REST API.
|
|
This allows you to send a request at a specific point during the login or registration flow with the data you defined in your action.
|
|
|
|
Example use case:
|
|
You want to send a request to an endpoint each time after an authentication (successful or not).
|
|
|
|
1. Define an action that calls API endpoint.
|
|
Make sure the name of the action is the same as of the function in the script.
|
|
Example how to call an API endpoint:
|
|
```ts reference
|
|
https://github.com/zitadel/actions/blob/main/examples/make_api_call.js
|
|
```
|
|
2. Add the action to the following flows and triggers
|
|
- Flow: Internal Authentication - Trigger: Post Authentication
|
|
- Flow: External Authentication - Trigger: Post Authentication
|
|
3. Authenticate user
|
|
4. Get data on your API
|