What would you like Teleport to do?
Emit Teleport Audit Log events when Teleport denies a user action due to authorization, including both default-denied actions and actions denied by explicit Teleport role deny rules.
The example below is Kubernetes-specific, but the same visibility would be useful across Teleport access protocols where Teleport makes the authorization decision, such as Kubernetes, SSH, Database Access, Application Access, and Desktop Access.
This may need to be configurable, since denied authorization attempts can be high-volume in some environments, especially for Kubernetes or automated clients. Operators may want to enable this visibility where it is useful for security monitoring without forcing every deployment to emit potentially noisy deny events.
Concrete Kubernetes example:
A user is allowed to get pods in a namespace, but tries to delete a pod in the same namespace. Teleport correctly denies the delete operation, but no Teleport Audit Log event is emitted for the denied attempt.
What problem does this solve?
This would help security teams detect privilege enumeration, brute-force attempts, or suspicious user behavior.
If a workaround exists, please include it.
No Teleport-native Audit Log workaround is currently known.
What would you like Teleport to do?
Emit Teleport Audit Log events when Teleport denies a user action due to authorization, including both default-denied actions and actions denied by explicit Teleport role deny rules.
The example below is Kubernetes-specific, but the same visibility would be useful across Teleport access protocols where Teleport makes the authorization decision, such as Kubernetes, SSH, Database Access, Application Access, and Desktop Access.
This may need to be configurable, since denied authorization attempts can be high-volume in some environments, especially for Kubernetes or automated clients. Operators may want to enable this visibility where it is useful for security monitoring without forcing every deployment to emit potentially noisy deny events.
Concrete Kubernetes example:
A user is allowed to get pods in a namespace, but tries to delete a pod in the same namespace. Teleport correctly denies the delete operation, but no Teleport Audit Log event is emitted for the denied attempt.
What problem does this solve?
This would help security teams detect privilege enumeration, brute-force attempts, or suspicious user behavior.
If a workaround exists, please include it.
No Teleport-native Audit Log workaround is currently known.