-
Notifications
You must be signed in to change notification settings - Fork 0
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
COSI-40, COSI-52: Revoke Bucket Access API Implementation and Tests #57
COSI-40, COSI-52: Revoke Bucket Access API Implementation and Tests #57
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files
... and 1 file with indirect coverage changes
@@ Coverage Diff @@
## main #57 +/- ##
==========================================
+ Coverage 90.69% 93.12% +2.42%
==========================================
Files 9 9
Lines 516 611 +95
==========================================
+ Hits 468 569 +101
+ Misses 38 36 -2
+ Partials 10 6 -4 |
ba8f6a1
to
e1e12fc
Compare
e1e12fc
to
cac48a6
Compare
@@ -145,3 +152,88 @@ func (client *IAMClient) CreateBucketAccess(ctx context.Context, userName, bucke | |||
|
|||
return accessKeyOutput, nil | |||
} | |||
|
|||
// RevokeBucketAccess is a helper that revokes bucket access by orchestrating individual steps to delete the user, inline policy, and access keys. | |||
func (client *IAMClient) RevokeBucketAccess(ctx context.Context, userName, bucketName string) error { |
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 I assume there is a 1-1 mapping between users and buckets, in which case it looks correct to me.
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.
There is a 1 to many mapping for buckets and users.
1 bucket can have multiple IAM users accessing it.
But for each access indeed we have 1 IAM user
mockIAM = &mock.MockIAMClient{} | ||
}) | ||
|
||
It("should fail on non-existent user gracefully", func(ctx SpecContext) { |
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.
The test says that it should fail "gracefully" but doesn't seem to check the gracefulness of the error (i.e. it tests the same way than the next test).
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.
Thank you for your feedback — it helped me catch a bug. I’ve added the change along with tests: if an access key is deleted between listing and deletion, we now handle it by returning a “not found” error and continuing with the list.
Additionally, I’ve created a ticket for next week to review the graceful handling of all errors, and I’ve added it to the next sprint: S3C-9439. I have more instances like this.
client.IAMService = mockIAM | ||
|
||
err := client.RevokeBucketAccess(ctx, "test-user", "test-bucket") | ||
Expect(err).To(BeNil()) |
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.
It would be good to check the side-effects of the function i.e. that it actually deleted stuff, although I don't know if this test suite is the good place where it can be done. It also applies to other tests around for function calls that have (or shouldn't have) side-effects.
One way I'm thinking about is attempting to use an access key that was revoked should not be possible, and conversely, using the access key that shouldn't have been revoked should still work. But that may be best done in E2E tests.
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.
We rely on Vault to handle the revocation of access keys, ensuring that deleted keys cannot be used. As such, this should not be tested in this particular test suite. Instead, the E2E tests verify the deletion of the IAM user, which falls under the scope of the COSI driver’s responsibility.
While I considered testing the deletion of the Kubernetes secret containing access, the responsibility for managing that lies with the COSI controller, not the COSI driver.
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.
Relying on contracts/promises from other services.
8b65b98
to
6e9393f
Compare
Addressed review comments, and added more tests for noSuchEntity scenarios. |
We do not need a prefix for inline policy, as bucket object is linked to access at kubernetes level, we keep inline policy name as bucket name
6e9393f
to
e27a1d2
Compare
- Gets parameters from the bucket object to get config for IAM client - Adds methods to IAM client to delete user, inline policy and keys - If inline policy doesn't exist, logs a warning and continues
- updated IAM mock with new IAM API methods - added unit tests for RevokeBucketAccess IAM API methods - removed the unimplemented test for RevokeBucketAccess
e27a1d2
to
07a2202
Compare
Summary
This PR implements the DriverRevokeBucketAccess API, enhances the IAM client, and adds comprehensive tests, including unit and end-to-end coverage.
Key Changes