User auditing for Cleanup policy for tags
Background
!24424 (merged) was a solution to a bug concerning which user to use to run the automated container expiration policies. That MR resolved the problem by bypassing the need for a user. Since a user with proper permissions created the policy, it was trusted that running the policy should be allowed.
However, it is important to know who created the policy that is currently running for admin/auditing purposes.
Proposal
There are two steps in adding the ability to know which user is creating/running which policies which can be broken into 4 MRs:
-
Add
user_id
tocontainer_expiration_policies
. When a user creates or updates a policy, the policy will be associated with that user, and subsequently, when the policy runs, it will authorize permissions against that user ID.- Iteration 1: Add
user_id
to thecontainer_expiration_policies
table and have it update when the policy is updated. The default value for existing policies can be theproject.creator_id
- Iteration 2: Update the
ContainerExpirationPolicyService
to use theCleanupContainerRepositoryWorker
and removeExpirationPolicyContainerRepositoryWorker
(revert much of !24424 (merged)) passing the new user into the cleanup service.- This can create problems if the user that last updated the policy has thier permissions changed or revoked. The automatically running container expiration policy will stop working due to the failed authorization, and it will do so quietly.
- Iteration 1: Add
-
Add a notification system so when a container expiration policy fails to run due to permissions, the admin user for that project/group is notified that the policy owner is no longer valid and a new user needs to be set.
- Iteration 1: add the notification so the admin user knows someone with proper permissions needs to go update the expiration policy so that it becomes active again.
- Iteration 2: add the ability for the admin user to assign the policy to another user without having to manually have that user go resave the policy.