A service account name may only be 32 characters long, which is easy to reach.

Handle it and put the overflow into the service account description.

The current MinIO (or S3?) behaviour is that it will fall back to the most rights instead of outright denying the application of the policy.

This means the service account (for example) has way more permissions than intended: instead of to a single bucket, to all buckets with the specified wildcard.

Implement automatic configuration of a service account specific to a bucket.

Currently, this is done in a bit of a convoluted way:

buckets:
  - name: infra-test-bucket-1

service_accounts:
  - name: infra-test-bucket-1
    bucket: infra-test-bucket-1

Having the ability to do this with one line in the same resource configuration would be a significantly better user experience.

Object locking / object retention enforces Write-Once Read-Many (WORM) immutability to protect versioned objects from deletion.

Crucial for mission-critical data.

https://min.io/docs/minio/linux/administration/object-management/object-retention.html

If we have a container image of the project we can use it much easier in pipelines.

It generates pages, but no content...

See https://alveel.github.io/minio-manager/

I realise there's manual documentation that should be done as well, but I think it should at least read all the code docs and generate technical documentation of classes and functions?

When a user has IAM policies configured, we currently just attach the policy every run.

Instead, we should verify what the current state is and only attach if it isn't already.

Code here

Right now there is no way to see what would change when running the application.

Introducing dry-run would allow running the application twice, requiring manual approval for the second, non-dry-run.

In a lot of S3 scenario's you want at least some sort of Object Lifecycle Management configured for your buckets. This issue is to implement that.

Instead of wrapping around the MinIO CLI client the functions it uses should be implemented in the MinIO Python library, specifically the MinioAdmin client.

The application is largely unaware of already existing resources.

In most places it does validate whether a resource exists and matches the configuration we have, but we do not check if there are for example any buckets that are not present in our resources.

We should inform users when this happens to reduce stale/lingering resources within MinIO/S3.

The code currently only allows to enable bucket versioning. There is not way to disable or suspend it.

In this code, we sort AWS IAM policy documents so we can compare the desired policy to the live policy without falling for simple order changes (JSON nor the AWS spec mandate a specific order).

If we can hard-code a limit for the allowed buckets to be created, we can deny buckets in the parse stage before attempting to create them at all.

For example MINIO_MANAGER_ALLOWED_BUCKET_PREFIX=infra-test- would deny the following resources:

buckets:
  - name: infra-acpt-deploy-1

Instead of Keepass we obviously want to use a better secret storage for this purpose.

HashiCorp Vault seems like an obvious choice.

They are effectively used for nearly the same purposes.

• ServiceAccount
• MinioCredentials

This includes access keys and secret keys, the latter which should really be masked.

Currently for most errors we catch we raise a custom exception. However this means we also get a full stack trace. Instead what we should get is a more concrete and informational log message with what went wrong and possible causes and fixes.

aka only throw exceptions when we're at a loss. If we kinda know what's going on, handle more gracefully.

If the secret backend is configured as keepass, if the user is just starting out, we should automatically generate the database.

Improve logging to show the log level before the message

If a bucket, service account, or IAM policy is defined multiple times with the same name we should catch that and not continue.