Using MINIO with kubernetes ambassador returns 'All access to this bucket has been disabled.' and 'the request signature does not match…'

[hmdevelopermind]

I am having a frustrating issue. I use MINIO as a object storage platform. I have it deployed in Open shift and in my open shift I have ambassador for routing. So when I use the direct route using ocp I am able to generate pre signed url and create buckets... so everything is fine but as soon I use ambasador as follows:

kind: Service
metadata:
  annotations:
    getambassador.io/config: |
      ---
      apiVersion: ambassador/v1
      kind: Mapping
      name: _api_minio
      service: "http://minio-svc:9000"
      prefix: /api/minio/
      rewrite: /
      bypass_auth: true
      host: ocicp8.xxx.xxx.xxxx.com
      add_response_headers:
        Strict-Transport-Security: max-age=15552000; includeSubDomains
        X-Frame-Options: SAMEORIGIN

So using ocicp8.xxx.xxx.xxxx.com/api/minio instead of direct route give me the following when I reach minio presigned url:

So I thought it might be because of rewrite: / and this issue happens so I changes my ambassador to the following:

  ---
  apiVersion: ambassador/v1
  kind: Mapping
  name: _api_minio10
  service: "http://minio-svc:9000"
  prefix: /minio/
  rewrite: ""
  bypass_auth: true
  host: ocicp8.xxx.xxx.xxxx.com
  add_response_headers:
    Strict-Transport-Security: max-age=15552000; includeSubDomains
    X-Frame-Options: SAMEORIGIN

As you see I changed rewrite: "" and now the redirection does not happen so as soon as I try the generated presigned url I get:

So now I am totally confused since the message is not really accurate as when I use the route not created by ambassador I am able to access access the file using presigned url so this message "access to this bucket is denied" is nonsense and misleading but I am not sure what is really happening. I do appreciate if anyone can help me

[kellerbr-ibm]

For using MinIO as an object store I would generally suggest using the MinIO SDKs.

I would agree that rewriting the URL will likely the presigned URL to no longer match the path that the server is expecting to be signed.

On the second rewrite it looks like it's accidentally getting routed to a bucket named minio, which is why it returns an access error.

[hmdevelopermind]

@kellerbr-ibm Thanks for the answer. Can you shed more light on

On the second rewrite it looks like it's accidentally getting routed to a bucket named minio, which is why it returns an access error.

So does that mean using ambassador is causing an issue and somehow confuses minio since direct url to minio works and when it comes to ambassador it acts this way?

[kellerbr-ibm]

It's adding a/minio to the URL in the spot where the bucket name goes, so the endpoint thinks that you're asking for the minio bucket.

[kellerbr-ibm]

@hamedminaee Were you able to get your issue resolved?

[hmdevelopermind]

@kellerbr-ibm Thanks for checking actually still waiting for our infrastructure team to get back to me I will update you about this so based on my undestanding if we have ocicp8.xxx.xxx.xxxx.com as a url we can not have a prefeix like ocicp8.xxx.xxx.xxxx.com/somePrefix at all since MINIO does not like it. Instead we need more of a s3 like url such as AddYourPath.ocicp8.xxx.xxx.xxxx.com right?

[kellerbr-ibm]

Yes, that's correct.

Did you manage to get your issue resolved?

[hmdevelopermind]

@kellerbr-ibm Yes and thanks a lot for the help