OPA integration: web console passes wrong bucket name

[bpedersen2]

Expected Behavior

A opa policy with the following rule:

# role-permissions assignments
rl_permissions := {
    "user": [{"action": "s3:CreateBucket"},
             {"action": "s3:DeleteBucket"},
             {"action": "s3:PutObjectLegalHold"},
             {"action": "s3:PutObjectRetention"},
             {"action": "s3:DeleteObject"},
             {"action": "s3:GetObject"},
             {"action": "s3:ListAllMyBuckets"},
             {"action": "s3:GetBucketObjectLockConfiguration"},
             {"action": "s3:GetBucketPolicyStatus"},
             {"action": "s3:HeadBucket"},

             {"action": "s3:GetBucketLocation"},
             {"action": "s3:ListBucket"},
             {"action": "s3:PutObject"}]
}

allow {
  username := input.claims.preferred_username
  input.bucket == username
  input.claims.iss == "http://resiopc1.office.frm2:8181/realms/MLZ"
  permissions := rl_permissions["user"]
  p := permissions[_]
  p == {"action": input.action}
}

should grant a user access to a bucket name like the user name.

Current Behavior

The access is denied while the bucket is listed in the overview page and the browse button is available. The opa logs show the following queries (where "versioned" is one example bucket of the iteration over all exisiting buckets):

 ....
opa_1     |   req_body = |
opa_1     |       {
opa_1     |         "input": {
opa_1     |           "account": "XXXXXXXXXXXXXX",
opa_1     |           "groups": null,
opa_1     |           "action": "s3:ListBucket",
opa_1     |           "bucket": "versioned",
.....
opa_1     | [INFO] Received request.
opa_1     |   req_method = "POST"
opa_1     |   req_path = "/v1/data/httpapi/authz/allow"
opa_1     |   req_body = |
opa_1     |       {
opa_1     |         "input": {
opa_1     |           "account":"XXXXXXXXXXXXX",
opa_1     |           "groups": null,
opa_1     |           "action": "s3:PutObject",
opa_1     |           "bucket": "versioned",

when trying to access a bucket named 'testbucket' from the web console.  It seems like access to all buckets is requested, as  besides the correct bucket, all other exisitig buckets are  also checked.

Accessing the same bucket from the commandline client is working.

## Your Environment

* Version used (`minio --version`): 2022-05-08T23:50:31Z
* Server setup and configuration: minio deployed via docker-compose (test setup) with keycloak and etcd configured 
* Operating System and version (`uname -a`): ubuntu 20.04

[harshavardhana]

@bpedersen2 the Console needs to check that - it is necessary for the UI element to verify what needs to be shown and what is not - why is that a problem?

[bpedersen2]

@harshavardhana :

It is not a problem if it checks it for the listings, but the browse access to the allowed bucket is never granted (clicking the browse button immediatly return to the bucket list instead...)

[harshavardhana]

ah and also console UI will not work yet with OPA since it does policy evaluation on its own - Console UI doesn't support OPA yet.

[harshavardhana]

You can only use S3 API at this point in time @bpedersen2

[bpedersen2]

Followup: To me it seems the console queries opa (via minio) almost correctly (I see the queries arriving at opa), just for listing bucket content there is a logical flaw: Instead of only requesting and evaluation the access to the current bucket, all buckets are queried and access is only granted if all queries return true.

so what I observe: go to browse bucket 'testuser1':

-> opa query for access to 'testbucket1' ==> result: true -> opa query for access to 'unrelated_bucket' ==> result: 'false' => results in listing not performed

[harshavardhana]

It was decided that if OPA is configured only S3 API-based access will be authorized, and Console UI access will not work. This is in line with the headless policies approach that OPA takes.

This won't be worked on unless there is a strong interest comes from our customers whoever is using it right now does not need Console UI access.