Add hability to create user

[Donatien26]

No description provided.

[sathieu]

@Donatien26 Thanks for your PR. I've left some comments. Back to you 🏓 !

[phlg]

Thank you very much for this big contribution. :)

Added my own batch of comments on top of Mathieu's (which by the way also apply to the other resources managed by s3-operator, I will need to fix that in the future).

Some are pretty important stuff that need to be discussed and/or implemented before approval (eg: README, group/policy considerations, status update method), some are minor nitpicks.

Will now clone the branch to do some local testing, might have other feedback afterwards.

[sathieu]

Please remove the groups part.

[phlg]

@Donatien26 We resumed tests today - still ongoing, but I'm wondering what we should do with the override-existing-secret.

With its default value of false, it means that if the accessKey stored inside the secret is changed, we have a mismatch between the actual working password (the initial value) and what's visible in the k8s secret. At this point, if the initial password is lost or deleted, then that S3User becomes unusable unless an admin resets the password, or both S3User and Secret resources are deleted and recreated.

Does that mean the Secret is considered a temporary commodity only, to first fetch the secret key and then store it somewhre else (eg: Vault) ? Or is it intended for a different reason (or unintended - in which case we might want to either change the default value or drop the flag) ?

[phlg]

Another thing of note : we need to test this further, but it looks like modifying just the accessKey in an existing S3User resource brings forth an incoherent state. Let's say the modification is this :

- - accessKey: user-a
+ - accessKey: user-b

Then :

• user-b is created on S3
• no user-b k8s Secret is created (which seems sane - there's still only one k8s S3User)
• user-a is not deleted on S3 (even with the s3user-deletion flag)
• it appears impossible to log in with either of them using the (unchanged) secret key (at least on Minio Console) EDIT : trying this again from scratch, it's actually still possible to log-in with user-a - but we do have a new user-b that is unable to log in

[phlg]

One last tidbit for today : I'm not if this is normal or not, but checking the YAML for the Secret tied to a S3User, the lastAppliedConfiguration annotation actually points to that of the S3User, not the secret.

Now there is an obvious link between the two, but I thought this was carried by the ownerReference. Is it normal that the Secret also carries the entire spec or its owning S3User ?

[phlg]

Can you add the right to remove a policy as well please ?

Suggested change

	"admin:CreatePolicy",
	"admin:CreatePolicy",
	"admin:DeletePolicy",