You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The presence of a username or service account related to Kubernetes as a field in the process execution is particularly important from a security perspective. Currently, we achieve this by correlating Tetragon events with Kubernetes API logs, which is a cumbersome process due to various issues such as delays and time drifts.
When an execution occurs, it is highly valuable to know exactly which user performed the action. It appears that such a feature has not yet been implemented in Tetragon for Kubernetes. Although I understand that this is not a simple task and has its own challenges, do you have any suggestions? Or is adding this feature in your roadmap?
Regards.
Describe your proposed solution
No response
Code of Conduct
I agree to follow this project's Code of Conduct
The text was updated successfully, but these errors were encountered:
cy83rc0llect0r
changed the title
Absence of Kubernetes Username Field to Tetragon Process Execution Events
Request for Adding Kubernetes Username Field to Tetragon Process Execution Events
Nov 15, 2024
cy83rc0llect0r
changed the title
Request for Adding Kubernetes Username Field to Tetragon Process Execution Events
Adding Kubernetes Username Field to Tetragon Process Execution Events
Nov 15, 2024
Is there an existing issue for this?
Is your feature request related to a problem?
No response
Describe the feature you would like
Hello,
The presence of a username or service account related to Kubernetes as a field in the process execution is particularly important from a security perspective. Currently, we achieve this by correlating Tetragon events with Kubernetes API logs, which is a cumbersome process due to various issues such as delays and time drifts.
When an execution occurs, it is highly valuable to know exactly which user performed the action. It appears that such a feature has not yet been implemented in Tetragon for Kubernetes. Although I understand that this is not a simple task and has its own challenges, do you have any suggestions? Or is adding this feature in your roadmap?
Regards.
Describe your proposed solution
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: