Conversation
Please find the detailed integration test report here Please find the Github Action logs here |
Add bytes and duration to presigned url audit log
5bf171a to
26880dd
Compare
Pull Request Test Coverage Report for Build 23218434397Details
💛 - Coveralls |
Please find the detailed integration test report here Please find the Github Action logs here |
|
Example from BDC Staging Specifically |
Avantol13
left a comment
There was a problem hiding this comment.
There are still some fields we should try to populate automatically if possible:
- dest_ip
- A little tricky, but maybe we can use request.environ and pull these fields like this:
server_name = request.environ.get('SERVER_NAME')
server_port = request.environ.get('SERVER_PORT')
# TODO: construct and add to audit logs- user_id_provider (e.g. RAS)
- Perhaps from
user.identity_provider.name?
- Perhaps from
- user_permission_group (e.g. dbGaP)
- This one's a little trickier. Maybe check if
config.dbGaPhas any entry withnih.govin the hostname? A little messy, but we allow non-NIH dbgap servers to be configured here (like in DCF), so we'll want something a little more foolproof. So if it's there, put "dbGaP". If it's not, put: "non-dbGaP"?
- This one's a little trickier. Maybe check if
- http_method
- This isn't required but it seems like we should just add it
- base it on the endpoint or do it automagically if this works:
method = request.environ.get('REQUEST_METHOD')
# TODO: add to audit logsCo-authored-by: Alexander VanTol <Avantol13@users.noreply.github.com>
uc-cdis/gen3-helm#492 This will get picked up by the X- header capturing
This is a tough one - fence/fence/blueprints/data/indexd.py Line 1660 in fa478fa fence/fence/blueprints/data/indexd.py Line 137 in fa478fa
I can add the config check but I don't think its a good solution for this. The best we have is the authzProvider here: https://github.com/uc-cdis/arborist/blob/master/arborist/user.go#L162 but we'll need to reach out to arborist or have this returned during the authz check and refactor fence code to ensure its present at time of audit (similar to the user_id_provider issue) tl;dr |
We can/should dump necessary user info into the token itself then. We already have some contextual user information embedded in access tokens (in context.user) - we could add user_id_provider and user_permission_group there, and then avoid db calls (just decode the token)? For RAS Passports, we can "hard-code" RAS and dbGaP for audit logs |
|
Test summary after running integration tests
Test summary after rerunning failed integration tests
Please find the detailed integration test report here Please find the detailed integration test report after rerunning failed tests here Please find the Github Action logs here |
Avantol13
left a comment
There was a problem hiding this comment.
added PD-141 to address user_id_provider and user_permission_group
Link to JIRA ticket if there is one:
New Features
Breaking Changes
Bug Fixes
Improvements
Dependency updates
Deployment changes