Summary
CreateAPIKey method invocations should generate audit events.
Current Behavior
When user runs coder login the CLI API Key gets created via CreateAPIKey
|
} else if !useTokenForSession { |
|
// If a session token is provided on the cli, use it to generate |
|
// a new one. This is because the cli `--token` flag provides |
|
// a token for the command being invoked. We should not store |
|
// this token, and `/logout` should not delete it. |
|
// /login should generate a new token and store that. |
|
client.SetSessionToken(sessionToken) |
|
// Use CreateAPIKey over CreateToken because this is a session |
|
// key that should not show on the `tokens` page. This should |
|
// match the same behavior of the `/cli-auth` page for generating |
|
// a session token. |
|
key, err := client.CreateAPIKey(ctx, "me") |
|
if err != nil { |
|
return xerrors.Errorf("create api key: %w", err) |
|
} |
|
sessionToken = key.Key |
|
} |
The corresponding method invocation lacks explicit audit.InitRequest function call which is required to generate audit log events
|
func (api *API) postAPIKey(rw http.ResponseWriter, r *http.Request) { |
|
ctx := r.Context() |
|
user := httpmw.UserParam(r) |
|
|
|
// TODO(Cian): System users technically just have the 'member' role |
|
// and we don't want to disallow all members from creating API keys. |
|
if user.IsSystem { |
|
api.Logger.Warn(ctx, "disallowed creating api key for system user", slog.F("user_id", user.ID)) |
|
httpapi.Forbidden(rw) |
|
return |
|
} |
|
|
|
cookie, _, err := api.createAPIKey(ctx, apikey.CreateParams{ |
|
UserID: user.ID, |
|
DefaultLifetime: api.DeploymentValues.Sessions.DefaultTokenDuration.Value(), |
|
LoginType: database.LoginTypePassword, |
|
RemoteAddr: r.RemoteAddr, |
|
}) |
As a result all events of this type are missing from the audit logs.
Proposed Changes
All invocations of the CreateAPIKey method should include the audit.InitRequest function call.