-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add remote address to failed/succeeded Bot/Instance joins #41452
Conversation
@@ -372,6 +372,7 @@ func (a *Server) RegisterUsingAzureMethod( | |||
if err != nil { | |||
return nil, trace.Wrap(err) | |||
} | |||
joinRequest = req.RegisterUsingTokenRequest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So before we were always calling handleJoinFailure
with nil
?
Also if I understand correctly, we don't log any information server-side if the challenge failes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it looks like there was a bug previously for IAM/Azure, my fault, but essentially it would never show the additional info.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this line be before the challenge block so we can log the details of the failed challenges?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately previous design has shot us in the foot here - we don't know the RegisterUsingTokenRequest before we've issued the challenge and received the response from the client. I have no clue why the client doesn't send this until we've issued the challenge /shrug
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😭 This makes troubleshooting failed joins way harder
@justinas are you able to take a look at this tomorrow, I'd like to try and get this shipped in the next release to unblock a customer's troubleshooting on Cloud. |
…failed-join-logging
@strideynet See the table below for backport results.
|
* Add connection metadata to instance join/bot join events * Add RemoteAddr to join failure/succsss logging
* Add connection metadata to instance join/bot join events * Add RemoteAddr to join failure/succsss logging
* Add connection metadata to instance join/bot join events * Add RemoteAddr to join failure/succsss logging
* Add connection metadata to instance join/bot join events * Add RemoteAddr to join failure/succsss logging
Closes #41421 partially - there's still a few potential cases where due to how we propagate the client IP, we actually don't know it until part of the way through the joining process (for challenge-response methods like IAM). We could eventually refactor to improve this and get this information at the start of the process.
changelog: Adds the remote address to audit log events emitted when a join for a Bot or Instance fails or succeeds.