Bug #53367
closed
Log S3 access key ID in ops logs
Added by Cory Snyder over 2 years ago.
Updated over 1 year ago.
Description
One use case for allowing multiple sets of S3 keys per RGW user account is to provide individual credentials for different applications or people who are accessing the same S3 resources. When using the ops logs for auditing purposes, it is important that we can distinguish which set of credentials were used to make a particular request so that we can pinpoint who was responsible (or which set of credentials may have been compromised). We should log the access key ID associated with each request to the ops logs, as applicable.
- Tracker changed from Bug to Feature
- Pull request ID set to 44052
(It would be nice to ensure that identity is logged appropriately for other auth strategies, too--we already have info specific to STS)
I agree, Matt. I'll take a closer look at the other auth strategies and try to determine what makes sense to log for each.
matt: I've taken a close look at each of the existing auth engines and here is my summary of what each does and what additional info we should include in the ops logs for each. Let me know if this sounds right to you?
keystone::EC2Engine Delegates S3 key pair check to Keystone. TODO: log the access key ID.
LDAPEngine Uses specially formatted, b64 encoded JSON access key. Should NOT log access key because it contains b64 encoded clear text user password. TODO: nothing
LocalEngine S3 key pairs are stored locally in RADOS for each user. TODO: log the access key ID and, if applicable, subuser
STSEngine Already logging the claims (including role name and role session name). TODO: log the access key ID.
S3AnonymousEngine No access key to log. TODO: nothing
SwiftAnonymousEngine No access key to log. TODO: nothing
swift::ExternalTokenEngine Just checks the swift token via a configurable external URL. TODO: Log subuser.
swift::SignedTokenEngine Rados implementation of Swift tokens. TODO: Log subuser.
swift::TempURLEngine TODO: Log which temp URL key was used? (1 or 2)
keystone::TokenEngine Keystone doesn't support RGW's subuser concept. TODO: nothing.
- Status changed from New to Resolved
- Backport set to pacific,quincy
- Affected Versions v0.52a added
I'll be happy to submit backports for pacific and quincy. I don't seem to have the ability to change the status to "Pending Backport".
- Status changed from Resolved to Pending Backport
- Backport changed from pacific,quincy to pacific quincy
- Tags set to backport_processed
- Tracker changed from Feature to Bug
- Status changed from Pending Backport to Resolved
- % Done changed from 0 to 100
- Tags deleted (
backport_processed)
- Regression set to No
- Severity set to 3 - minor
Also available in: Atom
PDF