Add real username/id of user who performed the action instead of host UUID to teleport audit logs

[deusxanima]

What

What would you like Teleport to do differently?

Customer would like to be able to parse session commands from audit log by user (teleport username). Some events, such as session.start contain a "user" field with this information. Others, like user.create, user.delete, reset_password_token.create...etc. pass the host UUID in place of the actual user's info in the "user" field.

How

How would you implement this?

Pass the teleport username to command logging like we do with session.start events.

Why

Why do you need this?

If a customer has multiple admins logged in, they currently see that the sessions have started with each admin's username, however, the payload of the command executed doesn't contain their username/userid, thus making it hard to impossible to properly correlate the events with an individual user.

[robertogiordani]

When will be included in the new 4.4.x version?

[russjones]

@Joerger When you implement this, can you investigate the difficulty in backporting to Teleport 4.4?

[Joerger]

Hi @robertogiordani, I think I have a solution for this issue. I reproduced the issue by starting a session on a node that is local to the auth server. When I then run tctl add user, the audit log has user:[server-uuid].

When you connect to auth directly like this, it uses the built in admin/system identity rather than the user's identity. In fact, the user's identity is not even discoverable when you connect to auth this way.

However, it is possible to connect to auth remotely with tctl --identity. When you connect to auth this way, the auditlog.user field is the teleport user. Fortunately this is now available in 4.4 as well. Does this fit your use case?

Note that in 4.4, some tctl methods may not be available through an identity file, and connecting remotely seems to be possible but a bit buggy. Your best bet would be to upgrade to 6.0+ if you can. In 6.1 you'd also gain access to impersonation which may aid with your use case.

[robertogiordani]

Thank you Brian, let me try. Regards, Roberto.

…

________________________________________________________________________________ Roberto Giordani Infrastructure Technical Security Lead IBM Rome Software Lab IBM Public Cloud phone +39.348.4327340 E-mail ***@***.*** WebMeeting https://ibm.webex.com/join/roberto.giordani IBM Italia S.p.A. Via Luigi Stipa, 150 - 00148 Rome From: Brian Joerger ***@***.***> To: gravitational/teleport ***@***.***> Cc: robertogiordani ***@***.***>, Mention ***@***.***> Date: 27/04/2021 23:50 Subject: [EXTERNAL] Re: [gravitational/teleport] Add real username/id of user who performed the action instead of host UUID to teleport audit logs (#6333) Hi @robertogiordani, I think I have a solution for this issue. I reproduced the issue by starting a session on a node that is local to the auth server. When I then run tctl add user, the audit log has user:[server-uuid]. When you connect to ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd Hi @robertogiordani, I think I have a solution for this issue. I reproduced the issue by starting a session on a node that is local to the auth server. When I then run tctl add user, the audit log has user:[server-uuid]. When you connect to auth directly like this, it uses the built in admin/system identity rather than the user's identity. In fact, the user's identity is not even discoverable when you connect to auth this way. However, it is possible to connect to auth remotely with tctl --identity. When you connect to auth this way, the auditlog.user field is the teleport user. Fortunately this is now available in 4.4 as well. Does this fit your use case? ? You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[robertogiordani]

@Joerger could you show me some example? The documentation is not clear for me and I've found this issue #1033
In that case how can we force the identify file creation and usage? We have to be sure that the operator doesn't forget to use the flag during the admin operations.
Thanks

[russjones]

@robertogiordani Please see #6771 where @Joerger has provided some examples of how to use tctl with an identity file.

If you are still running into issues, please feel free to re-open this ticket.