User ops audit log #7847
User ops audit log #7847
Conversation
|
👋 🤖 🤔 Hello, @alexronquillo! Did you make your changes in all the right places? These files were changed only in docs/. You might want to duplicate these changes in versioned_docs/version-8.8/.
You may have done this intentionally, but we wanted to point it out in case you didn't. You can read more about the versioning within our docs in our documentation guidelines. |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
alexronquillo
left a comment
alexronquillo
left a comment
There was a problem hiding this comment.
This is work-in-progress, as some of the features aren't yet developed, and some details are still being discussed. Therefore, there's no need for a tech writer review yet. Instead, the current goal for this draft is to get engineers' eyes on the content to make sure I'm headed in the right direction. After all decisions have been made, and the docs are complete, I'll request a language review.
| | **User** | `*`, `felix.mueller` | All users / Username | `CREATE`, `READ`, `UPDATE`, `DELETE` | | ||
| | Resource type | Resource key example | Resource key type | Supported permissions | | ||
| | :----------------------------------- | :------------------------------------------- | :----------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| | **Audit Log** | `*`, `category_name` | All audit logs / category name | `READ` | |
There was a problem hiding this comment.
Added the Audit Log to the list of available resources.
| | **Group** | `*`, `accounting` | All groups / Group ID | `CREATE`, `READ`, `UPDATE`, `DELETE` | | ||
| | **Mapping Rule** | `*`, `my_mapping` | All mappings / Mapping ID | `CREATE`, `READ`, `UPDATE`, `DELETE` | | ||
| | **Message** | `*` | All messages | `CREATE`, `READ` | | ||
| | **User Task** | assignee, candidateUsers, or candidateGroups | - | `READ`, `UPDATE`, `CLAIM`, `COMPLETE` | |
There was a problem hiding this comment.
Added the User Task to the list of available resources.
| In Identity, you can audit all [`ADMIN` operations](../user-operations-audit-log/overview/recorded-operations.md#admin-operations): | ||
|
|
||
| 1. In the top navigation, click **Operations log**. | ||
| 2. To sort the log, click a column header. |
There was a problem hiding this comment.
I'm not sure if this second step is necessary. My rational was twofold:
- The document felt plain with a single step
- Users might find it helpful to know they can sort the log while auditing
| | Modify process instances | `Process Definition` | ID of the respective BPMN process definition or `*` (for all process definitions). | `MODIFY_PROCESS_INSTANCE` | | ||
| | Cancel process instance directly | `Process Definition` | ID of the respective BPMN process definition or `*` (for all process definitions). | `CANCEL_PROCESS_INSTANCE` | | ||
| | Delete process instances | `Process Definition` | ID of the respective BPMN process definition or `*` (for all process definitions). | `DELETE_PROCESS_INSTANCE` | | ||
| | View `DEPLOYED_RESOURCES` and `USER_TASKS` operations for instances of a specific process definition. | `Process Definition` | A process definition ID or `*` for all process definitions. | `READ_PROCESS_INSTANCE` | |
There was a problem hiding this comment.
Because we've added the operations log, I added the corresponding authorizations under "Optional authorizations"
|
|
||
| However, only operations that are authenticated, authorized, and reach execution with a success or execution‑time failure are recorded. Operations rejected before execution aren't recorded in the audit log. | ||
|
|
||
| Additionally, only user operations are tracked by default, not [client](../../zeebe/technical-concepts/architecture.md#clients) operations. Unlike the other constraints, you can configure this behavior. |
There was a problem hiding this comment.
I believe this decision isn't final. Please let me know if we should change this. Also, are there any other limitations/constraints we should cover here? I know API v2 is a constraint, but since v1 is fully deprecated to the best of my knowledge, I didn't think it was necessary.
There was a problem hiding this comment.
Unlike the other constraints, you can configure this behavior.
When the configuration functionality is implemented, I'll write the corresponding guide and link to it from here and other places.
There was a problem hiding this comment.
Following up: The decision to only track user ops by default is final (as described here).
| The audit log contains operations performed using: | ||
|
|
||
| - [Operate](../../operate/userguide/audit-operations.md), [Identity](../../identity/audit-operations.md), and [Tasklist](../../tasklist/userguide/audit-task-history.md) | ||
| - [Orchestration Cluster REST API](../../../apis-tools/orchestration-cluster-api-rest/specifications/search-audit-logs.api.mdx) |
There was a problem hiding this comment.
I didn't see any operations triggered via API in the log during testing, but I may have misconfigured something. Please correct me if I'm wrong here.
|
|
||
| | Operation | Entity | Tracked rejections | | ||
| | :------------------- | :------------------ | :----------------- | | ||
| | Create Authorization | Authorization | – | |
There was a problem hiding this comment.
Despite the fact that no rejections are tracked for ADMIN operations, I left the column because it's there for the other categories, and I didn't want to confuse readers.
docs/components/user-operations-audit-log/overview/recorded-operations.md
Outdated
Show resolved
Hide resolved
| The user operation audit log is enabled by default. Because of the increase in resource usage on secondary storage, you may see increased costs associated with this feature. | ||
| ::: | ||
|
|
||
| You can configure the user operations audit log to fine-tune log thoroughness, resource usage, and financial costs according to your needs. Additionally, if using Camunda 8 Self-Managed, you control the [secondary storage retention policy](../../self-managed/components/orchestration-cluster/core-settings/configuration/properties.md#index--retention-settings), which applies to user operation audit log records. |
There was a problem hiding this comment.
When the configuration functionality is implemented, I'll write the corresponding guide and link to it from here and other places.
|
FYI @alexronquillo I think this feature is now moved to alpha 5 |
alexronquillo
force-pushed
the
user-ops-audit-log
branch
from
4aa100c to
1f01b7b
Compare
koevskinikola
left a comment
koevskinikola
left a comment
There was a problem hiding this comment.
Hey @alexronquillo, reviewed the draft docs. They look pretty good, I really like how you structured them.
I left some feedback below.
🔧 I also struggled initially to find the audit log docs when I set up the docs locally. It might be good to have some mention of this feature in the Self-Managed part of the docs, as SM users will be more impacted by the secondary storage increase in usage.
| | Unassign task | User task | INVALID_STATE | | ||
| | Complete task | User task | INVALID_STATE | | ||
| | Update task | User task | INVALID_STATE | | ||
| | Command rejection | Command entity type | – | |
There was a problem hiding this comment.
🤔 If we're documenting the Command rejection operation here, then the Entity is User task. This might make it clearer to users.
There was a problem hiding this comment.
Do you think it's necessary to keep this row or is the Tracked rejections column sufficient?
docs/components/user-operations-audit-log/overview/recorded-operations.md
Outdated
Show resolved
Hide resolved
docs/components/user-operations-audit-log/overview/recorded-operations.md
Outdated
Show resolved
Hide resolved
|
|
||
| 1. In the top navigation, click **Operations Log**. | ||
| 2. To sort the log, click a column header. | ||
| 3. To see the details of a particular operation, click the info icon at the end of the row. |
There was a problem hiding this comment.
🔧 We will also add some filtering in the general audit log tab. But let's only document this when it's added.
koevskinikola
left a comment
koevskinikola
left a comment
There was a problem hiding this comment.
Hey @alexronquillo, I reviewed the draft docs. They look pretty good, I really like how you structured them.
I left some feedback below.
🔧 I also struggled initially to find the audit log docs when I set up the docs locally. It might be good to have some mention of this feature in the Self-Managed part of the docs, as SM users will be more impacted by the secondary storage increase in usage.
|
The preview environment relating to the commit efae079 has successfully been deployed. You can access it at https://preview.docs.camunda.cloud/pr-7847/ |
3 participants
Description
Closes: #6925
When should this change go live?
bugorsupportlabel)available & undocumentedlabel)holdlabel)low priolabel)PR Checklist
{type}(scope): {description}commit message(s)My changes are for an upcoming minor release and are in the
/docsdirectory (version 8.9).My changes are for an already released minor and are in a
/versioned_docsdirectory.I included my new page in the sidebar file(s).
I added a DRI, team, or delegate as a reviewer for technical accuracy and grammar/style:
@camunda/tech-writersunless working with an embedded writer.