Minio custom access keys won't allow login to dashboard

[jbmcfarlin31]

Is this a bug report or feature request?

• Bug Report

Bug Report
When using a custom generated access key and secret key to access the minio object store, I get an error saying The access key ID you provided does not exist in our records.

Expected behavior:
I would be able to login with the generated access keys.

Deviation from expected behavior:
I was deploying the sample code from the cluster/examples/kubernetes/minio directory. The only thing that was modified was the secret containing the username and password fields (respectively access key and secret key used for minio). I then changed the storage class to be what I am using (in this case rook-ceph).

How to reproduce it (minimal and precise):

I just kubectl create -f operator.yaml and waited for it to come up. Then when it was successful I did a kubectl create -f object-store.yaml ensuring to enter my new credentials as base64 encoded values.

The my-store-x pods came up, I was able to access my minio dashboard via my ingress rule that I defined for it, and upon trying to login to the dashboard with the generated credentials I get the error mentioned above.

Nothing shows in the operator log or the my-store-x pods.

I took the same object-store.yaml file and left the default values for credentials ("TEMP_DEMO_ACCESS_KEY and TEMP_DEMO_SECRET_KEY") and redeployed after deleting everything and was able to login.

I should also note that with the custom credentials, I see them in the pods and statefulset as ENV vars with the correct values.

File(s) to submit:

• Cluster CR (custom ressource), typically called cluster.yaml, if necessary
• Operator's logs, if necessary
• Crashing pod(s) logs, if necessary

To get logs, use kubectl -n <namespace> logs <pod name>
When pasting logs, always surround them with backticks or use the insert code button from the Github UI.
Read Github documentation if you need help.

Environment:

• OS (e.g. from /etc/os-release): Ubuntu 16.04
• Kernel (e.g. uname -a):
• Cloud provider or hardware configuration: Azure Stack
• Rook version (use rook version inside of a Rook Pod): v0.9.3
• Storage backend version (e.g. for ceph do ceph -v): ceph 0.9.3
• Kubernetes version (use kubectl version): 1.13.5
• Kubernetes cluster type (e.g. Tectonic, GKE, OpenShift): RKE
• Storage backend status (e.g. for Ceph use ceph health in the Rook Ceph toolbox):

[jbmcfarlin31]

Got this resolved. I actually found the fix for it on the minio/minio github project as a related issue. The problem seemed to be that when base64 encoding the values, you need to be sure that newlines and feeds do not get into it. I am not sure how that occurred for me but my command looked something like echo "supsersecretpassword" | base64 and that was failing.

What I had to do instead was:

$ cat minio-object-store.yml
...
apiVersion: v1
kind: Secret
metadata:
  name: minio-access-keys
  namespace: minio
type: Opaque
data:
  MINIO_ACCESS_KEY: #1
  MINIO_SECRET_KEY: #2
...
$ MINIO_ACCESS_KEY=$(echo -n "username" | base64 -w0)
$ MINIO_SECRET_KEY=$(echo -n "password" | base64 -w0)
$ sed -i "s/#1/$MINIO_ACCESS_KEY/g" minio-object-store.yml
$ sed -i "s/#2/$MINIO_SECRET_KEY/g" minio-object-store.yml

The link for the fix can be found here: Using Env vars for Minio Access/Secret Keys.

Hope this helps some folks!

[galexrt]

@jbmcfarlin31 Would you be up to document on Rook's side so other people are not running into this as well? 🙂

[jbmcfarlin31]

@galexrt Sure, I don't mind at all! Please let me know where to go / what to do and I will get started on it.

[galexrt]

@jbmcfarlin31 Thanks!
That would be this page https://rook.io/docs/rook/v1.0/minio-object-store-crd.html, so this file https://github.com/rook/rook/blob/master/Documentation/minio-object-store-crd.md.

For more info https://github.com/rook/rook/blob/master/CONTRIBUTING.md and / or hit me up on the Rook Slack, see https://slack.rook.io/.

[jbmcfarlin31]

@galexrt I just submitted the PR today. Please let me know if anything needs to change.