MinIO Operator HashiCorp Consul Integration

[jyousefpour1]

When integrating the MinIO operator with HashiCorp Consul service mesh we ran into issues with the serviceAccount assignments used throughout the operator/tenant deployments. A requirement on the Consul side is that every service that needs to be able to receive traffic be tied to a unique serviceAccount with the same name. We were able to update the SA used in the operator, but have been unsuccessful in deploying a tenant so far. Any pod where the service account name does not match will ultimately fail to start, but when deploying the tenant, it hangs on the initialization and we can't find anywhere to further diagnose the issue.

Expected Behavior

logs are shown when the user runs kubectl describe tenant TENANT -n minio-operator

Current Behavior

The tenant does not show any status when it's created

Steps to Reproduce (for bugs)

1. Integrate MinIO operator with HashiCorp consul
2. Attempt to create Tenant using MinIO Operator console
3. Monitor Behavior of the tenant

Context

• Version used (minio-operator): 5.0.11
• Environment name and version (e.g. kubernetes v1.17.2): RKE 1.26
• Server type and version:
• Operating System and version (uname -a): RHEL 8
• Link to your deployment file:

[cniackz]

These are the service accounts for Operator:

$ k get serviceaccounts -n minio-operator
NAME             SECRETS   AGE
console-sa       0         16h
default          0         16h
minio-operator   0         16h

These are the service accounts for the tenant:

$ k get serviceaccounts -n tenant-lite
NAME         SECRETS   AGE
default      0         16h
myminio-sa   0         16h

I would like to know how exactly the service accounts were modified in order to reproduce it locally

When you run this command below, it is not good practice nor expected to have the tenant in the same namespace as the operator for security reasons:

kubectl describe tenant TENANT -n minio-operator

Each tenant should have its own namespace

What do you mean by be tied to a unique serviceAccount with the same name.? How was this change made? can you please share the service accounts you are currently using and describe what changes were done

Thank you @joseph Yousefpour for the issue and the information already provided; we want to look further into this.

Also, since you created a tenant, can you share with us the tenant spec?

From the tenant spec, I want to see the namespace of it

so that then we can request the logs or events if ss is deployed and or if pods are deployed

Normally we get logs from different resources depending the issue, places are:

• Operator logs
• MinIO Pod Logs/Events
• StatefulSet Events

And depending on the issues, we may need to explore differently or further into other resources.
To my understanding, altering the service accounts in a manner that affects the Operator could potentially lead to various issues. We can collaboratively explore this situation to ascertain which specific RBAC permissions are either lacking or required by the Operator. This will enable us to take appropriate action accordingly.