[question or bug] how to configure tenant to map a oidc user group to a specific policy?

[davgia]

Hi,

I have the following tenant:

apiVersion: rustfs.com/v1alpha1
kind: Tenant
metadata:
  name: test
  namespace: rustfs
spec:
  buckets:
  - name: shared-files
  credsSecret:
    name: rustfs
  env:
  - name: RUSTFS_IDENTITY_OPENID_ENABLE
    value: "true"
  - name: RUSTFS_IDENTITY_OPENID_CONFIG_URL
    value: https://keycloak.example.com/realms/example/.well-known/openid-configuration
  - name: RUSTFS_IDENTITY_OPENID_SCOPES
    value: openid,profile,email,groups
  - name: RUSTFS_IDENTITY_OPENID_GROUPS_CLAIM
    value: groups
  - name: RUSTFS_IDENTITY_OPENID_USERNAME_CLAIM
    value: preferred_username
  - name: RUSTFS_IDENTITY_OPENID_ROLE_POLICY
    value: consoleAdmin
  - name: RUSTFS_IDENTITY_OPENID_DISPLAY_NAME
    value: Keycloak
  - name: RUSTFS_IDENTITY_OPENID_REDIRECT_URI
    value: https://rustfs.example.com/rustfs/admin/v3/oidc/callback/keycloak
  - name: RUSTFS_IDENTITY_OPENID_CLIENT_ID
    valueFrom:
      secretKeyRef:
        key: client-id
        name: rustfs-oidc
  - name: RUSTFS_IDENTITY_OPENID_CLIENT_SECRET
    valueFrom:
      secretKeyRef:
        key: client-secret
        name: rustfs-oidc
  image: REDACTED.dkr.ecr.eu-west-1.amazonaws.com/docker.io/rustfs/rustfs
  imagePullSecret:
    name: aws-ecr-pull-secrets
  mountPath: /data
  policies:
  - document:
      configMapKeyRef:
        key: policy-administrators.json
        name: rustfs-policies
    name: administrators
  - document:
      configMapKeyRef:
        key: policy-maintainers.json
        name: rustfs-policies
    name: maintainers
  - document:
      configMapKeyRef:
        key: policy-developers.json
        name: rustfs-policies
    name: developers
  - document:
      configMapKeyRef:
        key: policy-shared-readwrite.json
        name: rustfs-policies
    name: shared-readwrite
  pools:
  - name: primary
    persistence:
      volumeClaimTemplate:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 64Gi
        storageClassName: nfs-client
      volumesPerServer: 1
    servers: 1
  users:
  - name: shared
    policies:
    - shared-readwrite
status:
  provisioning:
    users:
    - desiredHash: sha256:cc76eeab87ad3727c40d72dfae3025939eeff56f470e6319db9cdde86c4b28b3
      lastTransitionTime: "2026-07-10T20:13:58Z"
      message: 'failed to apply RustFS policy ''maintainers'': upstream returned 400
        Bad Request'
      name: maintainers
      reason: PolicyApplyFailed
      state: Failed

This is my configmap:

apiVersion: v1
data:
  policy-administrators.json: '{"Statement":[{"Action":["s3:*"],"Condition":{"ForAnyValue:StringEquals":{"jwt:groups":["administrators"]}},"Effect":"Allow","Resource":"*"}],"Version":"2012-10-17"}'
  policy-developers.json: '{"Statement":[{"Action":["s3:GetBucketLocation","s3:ListBucket","s3:GetObject"[],"Condition":{"ForAnyValue:StringEquals":{"jwt:groups":["developers"]}},"Effect":"Allow","Resource":"*"}],"Version":"2012-10-17"}'
  policy-maintainers.json: '{"Statement":[{"Action":["s3:*"],"Condition":{"ForAnyValue:StringEquals":{"jwt:groups":["maintainers"[]}},"Effect":"Allow","Resource":"*"},{"Action":["s3:PutBucketPolicy","s3:PutBucketAcl","s3:PutObjectAcl","s3:DeleteObject","s3:DeleteObjectVersion","s3:DeleteBucket"[],"Condition":{"ForAnyValue:StringEquals":{"jwt:groups":["maintainers"]}},"Effect":"Deny","Resource":"*"}],"Version":"2012-10-17"}'
  policy-shared-readwrite.json: '{"Statement":[{"Action":["s3:*"],"Effect":"Allow","Resource":["arn:aws:s3:::shared-files","arn:aws:s3:::shared-files/**"]}],"Version":"2012-10-17"}'
kind: ConfigMap
metadata:
  labels:
    rustfs.tenant: test
  name: rustfs-policies
  namespace: rustfs

Is the condition supported? Judging from the error it is not. Can I achieve the same result with a different approach supported by rustfs? I would like to avoid manually configuring it from web ui.

Thanks!

[davgia]

If anyone is in the same situation, my error was this one:

"Resource": "*" is invalid, the correct pattern is "Resource": "arn:aws:s3:::*". If I remember correctly minio was accepting it. I don't know for S3. This is a difference. Maybe more details in the tenant events or operator log about the error would be very helpful.

To test a policy I suggest trying to apply it from the webui, it gives a much more helpful error

[GatewayJ]

Thanks for the follow-up. I checked the operator and RustFS policy path, and your latest comment matches the actual failure.

The Condition block is not the reason this policy was rejected. RustFS does support jwt:groups as a policy condition key, but the policy failed earlier while parsing the Resource field. RustFS expects S3 resources to use ARN form, so:

"Resource": "*"

is rejected, while patterns such as these are valid:

"Resource": "arn:aws:s3:::*"

or, for bucket/object access:

"Resource": [
  "arn:aws:s3:::shared-files",
  "arn:aws:s3:::shared-files/*"
]

For OIDC group-to-policy mapping, the more natural RustFS approach is to let the OIDC groups claim map to canned policy names. With RUSTFS_IDENTITY_OPENID_GROUPS_CLAIM=groups, groups from the token are mapped to policy names, so if your Keycloak groups are administrators, maintainers, developers, etc., creating canned policies with those same names through spec.policies should allow RustFS to resolve them declaratively.

One thing to watch: RUSTFS_IDENTITY_OPENID_ROLE_POLICY=consoleAdmin is a default policy for the OIDC provider, so it applies broadly to users from that provider. If the goal is per-group permissions, it may be better to rely on group-derived policy names instead of assigning the same role policy to everyone.

The operator-side gap here is diagnostics. Today the operator records only upstream returned 400 Bad Request in the Tenant provisioning status/event, because the RustFS admin client drops the response body on non-2xx responses. We should improve that so PolicyApplyFailed includes the RustFS parse error in the Tenant status, events, and logs.

[davgia]

hi @GatewayJ,

shortly after creating the issue I removed RUSTFS_IDENTITY_OPENID_ROLE_POLICY env var because I understood what it did. As you notes can give full access to unwanted users. Now I have a stable tenant and I can test it properly. I have completely substituted bitnami minio with rustfs-operator now. I have migrated all objects too.

If the test succeed I will try it in prod. So far great experience... I will wait the first official release too!

[GatewayJ]

Thank you for trusting RustFS and for sharing your real-world experience, @davgia! We’re delighted to hear that your
migration to rustfs-operator is going well.

Your detailed feedback is extremely valuable to us. We have already started improving the policy diagnostics in #180, and
we will continue to make RustFS and the operator easier to use.

Please keep reporting any issues, unexpected behavior, or suggestions you encounter. We’ll investigate them promptly and
work to resolve confirmed issues as quickly as possible.

Thanks again for your support. We’re looking forward to supporting your production rollout and to your feedback as we
prepare the first official release.