Thank you, Pritha, I am most grateful.
As you have "{sts key for encrypting the session token}" with {} marking
something that needs to be replaced, perhaps the doc could be changed to
also add a "{name}" in the section header? Putting it under [global] also
worked.
Best regards,
Michael
On Wed, 24 Nov 2021 at 10:55, Pritha Srivastava <prsrivas@xxxxxxxxxx> wrote:
>
>
> On Wed, Nov 24, 2021 at 3:41 PM Michael Breen <
> michael.breen@xxxxxxxxxxxxxxxxxxxx> wrote:
>
>> Thank you, Pritha!
>> aud != client_id was the immediate problem (there is another...). For
>> anyone else who comes across this thread, go directly to
>>
>>
>> https://issues.redhat.com/browse/KEYCLOAK-8954?focusedCommentId=13979543&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13979543
>>
>> It would be great if the reason for this kind of failure was included in
>> the Ceph debug log, then someone could do a search and might find the above
>> page. A lot of debug output has been added (one of the reasons I went to
>> the master branch to try to figure out this problem) but messages giving
>> the specific reason for such a rejection would be very helpful. Regarding
>> IAM-related code not in any released version, do a grep for e.g.
>> principal_tags.
>>
>
> The code related to principal_tags is on master only.
>
>>
>> The problem that remains - I hope the last one - is
>>
>> sts:assume_role_web_identity ERROR: Invalid rgw sts key, please ensure
>> its length is 16
>>
>> Some others seem to have encountered this
>> https://stackoverflow.com/questions/65420090/how-to-config-ceph-rgw-sts-key
>> but no solution is described there. I have tried various things - the one
>> at https://docs.ceph.com/en/latest/radosgw/STS/
>>
>> [client.radosgw.gateway]
>> rgw sts key = abcdefghijklmnop
>> rgw s3 auth use sts = true
>>
>> Also
>>
>> [client.radosgw.gateway]
>> rgw_s3_auth_use_sts = true
>> rgw_sts_key = "1234567890123456"
>>
>> and some others. It's something simple again I expect, but not obvious to
>> me. Any ideas?
>>
>
> How have you named your rgw? You will have to ensure that your rgw section
> name is correct, else for testing you can add it to the global section - it
> should work. The one given in the documentation:
> https://docs.ceph.com/en/latest/radosgw/STS/ works.
>
> Thanks,
> Pritha
>
>> Best regards,
>> Michael
>>
>>
>> On Wed, 24 Nov 2021 at 03:50, Pritha Srivastava <prsrivas@xxxxxxxxxx>
>> wrote:
>>
>>> Hi Michael,
>>>
>>> My responses are inline:
>>>
>>> On Tue, Nov 23, 2021 at 10:07 PM Michael Breen <
>>> michael.breen@xxxxxxxxxxxxxxxxxxxx> wrote:
>>>
>>>> Hi Pritha - or anyone who knows,
>>>>
>>>> I too have problems with IAM, in particular
>>>> with AssumeRoleWithWebIdentity.
>>>>
>>>> I am running the master branch version of Ceph because it looks like it
>>>> includes code related to the functionality described at
>>>> https://docs.ceph.com/en/latest/radosgw/STS/ - code which is not in
>>>> any released version, even 17.0.
>>>>
>>>> Looking at the code on that page, there appear to be at least two
>>>> errors:
>>>> (1) an instance of "client" should be "sts_client" (or vice versa)
>>>> (2) an access key and secret key are specified when creating
>>>> sts_client, which is unnecessary and therefore confusing: only the access
>>>> token is used or should be required for assume_role_with_web_identity
>>>>
>>>
>>> I agree, these can be corrected. However I don't understand what you
>>> mean by saying that this - "code which is not in any released version,
>>> even 17.0."
>>>
>>>>
>>>> But I still cannot get the AssumeRoleWithWebIdentity code example to
>>>> work. The RGW debug logs show
>>>>
>>>> debug 2021-11-23T15:51:22.247+0000 7fad6e351700 0 evaluating policy
>>>> for op: 93 returned deny/pass
>>>>
>>>> In my case, the policy_document and role_policy are
>>>>
>>>> policy_document =
>>>> '''{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"Federated":["arn:aws:iam:::oidc-provider/proteus.ves.corp/auth/realms/cno"]},"Action":["sts:AssumeRoleWithWebIdentity"],"Condition":{"StringEquals":{"proteus.ves.corp/auth/realms/cno:app_id":"ceph_rgw"}}}]}'''
>>>> role_policy =
>>>> '''{"Version":"2012-10-17","Statement":{"Effect":"Allow","Action":"s3:*","Resource":"arn:aws:s3:::*"}}'''
>>>>
>>>>
>>>
>>>> (I assume it is only the former that may be relevant here, but maybe
>>>> I'm wrong.)
>>>>
>>>
>>> The former is only relevant here. And have you created an openid connect
>>> provider in RGW? ( I am assuming you must have, since it is there in the
>>> examples given). You have set the condition as app_id: ceph_rgw. Whereas
>>> the documentation says that - "The app_id in the condition above must
>>> match the ‘aud’ claim of the incoming token." in the example which uses
>>> "app_id" as a condition element, and the value of "aud" is "account" in
>>> the web token. So please modify the condition accordingly. Also note
>>> that other claims can also now be used in the condition element of the
>>> trust policy.
>>>
>>>>
>>>> In /etc/ceph/ceph.conf I have
>>>> [client.radosgw.gateway]
>>>> rgw sts key = abcdefghijklmnop
>>>> rgw s3 auth use sts = true
>>>>
>>>> In the debug I can see the token from Keycloak looks like (after
>>>> formatting it)
>>>>
>>>> {
>>>> "exp": 1637677729,
>>>> "iat": 1637677429,
>>>> "jti": "06e5422e-8395-4727-9366-a851c3f5930f",
>>>> "iss": "https://proteus.ves.corp/auth/realms/cno";,
>>>> "aud": "account",
>>>> "sub": "f45bae70-1517-48f6-9d75-af7f421f4a0c",
>>>> "typ": "Bearer",
>>>> "azp": "ceph_rgw",
>>>> "session_state": "1413beec-9785-4e63-947f-72eb26da9daf",
>>>> "acr": "1",
>>>> "allowed-origins": [
>>>> "*"
>>>> ],
>>>> "realm_access": {
>>>> "roles": [
>>>> "offline_access",
>>>> "uma_authorization"
>>>> ]
>>>> },
>>>> "resource_access": {
>>>> "ceph_rgw": {
>>>> "roles": [
>>>> "arn:aws:iam:::role/S3Access",
>>>> "S3Access"
>>>> ]
>>>> },
>>>> "account": {
>>>> "roles": [
>>>> "manage-account",
>>>> "manage-account-links",
>>>> "view-profile"
>>>> ]
>>>> }
>>>> },
>>>> "scope": "openid profile email",
>>>> "email_verified": true,
>>>> "name": "testuser",
>>>> "preferred_username": "testuser",
>>>> "given_name": "testuser",
>>>> "email": "test-user@xxxxxxxxxxxxxxxxxx"
>>>> }
>>>>
>>>> Please, if you are familiar with this, can you tell me what step is
>>>> missing? There is no description on that page of what should be done at
>>>> Keycloak, so I'm guessing the problem may be there. (Keycloak screens are
>>>> shown elsewhere, but for a different example.) I have spent a good deal of
>>>> time trying to understand this, so if you could help I would greatly
>>>> appreciate it.
>>>> Kind regards,
>>>> Michael
>>>>
>>>
>>> If you can paste further logs here then I will be able to help you. Also
>>> Ceph documentation explains how to get a token from Keycloak and proceed
>>> with that. For any other Keycloak configurations, please refer to Keycloak
>>> documentation.
>>>
>>> Thanks,
>>> Pritha
>>>
>>>>
>>>> On Tue, 23 Nov 2021 at 06:22, Pritha Srivastava <prsrivas@xxxxxxxxxx>
>>>> wrote:
>>>>
>>>>> Hi Nio,
>>>>>
>>>>> Can you provide more details around what you are trying to do?
>>>>>
>>>>> RGW supports attaching IAM policies to users that aid in managing their
>>>>> permissions.
>>>>>
>>>>> Thanks,
>>>>> Pritha
>>>>>
>>>>> On Tue, Nov 23, 2021 at 11:43 AM nio <nioshield@xxxxxxxxx> wrote:
>>>>>
>>>>> > hi，all:
>>>>> > In the process of using RGW, I still cannot authenticate users
>>>>> through
>>>>> > IAM. In the near future, will RGW support IAM to manage user
>>>>> permissions
>>>>> > and authentication functions?
>>>>> >
>>>>> >
>>>>> > Looking forward to your reply 😁
>>>>> > _______________________________________________
>>>>> > ceph-users mailing list -- ceph-users@xxxxxxx
>>>>> > To unsubscribe send an email to ceph-users-leave@xxxxxxx
>>>>> >
>>>>> _______________________________________________
>>>>> ceph-users mailing list -- ceph-users@xxxxxxx
>>>>> To unsubscribe send an email to ceph-users-leave@xxxxxxx
>>>>>
>>>>
>>>> CONFIDENTIALITY
>>>> This e-mail message and any attachments thereto, is intended only for
>>>> use by the addressee(s) named herein and may contain legally privileged
>>>> and/or confidential information. If you are not the intended recipient of
>>>> this e-mail message, you are hereby notified that any dissemination,
>>>> distribution or copying of this e-mail message, and any attachments
>>>> thereto, is strictly prohibited. If you have received this e-mail message
>>>> in error, please immediately notify the sender and permanently delete the
>>>> original and any copies of this email and any prints thereof.
>>>> ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS
>>>> NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform
>>>> Electronic Transactions Act or the applicability of any other law of
>>>> similar substance and effect, absent an express statement to the contrary
>>>> hereinabove, this e-mail message its contents, and any attachments hereto
>>>> are not intended to represent an offer or acceptance to enter into a
>>>> contract and are not otherwise intended to bind the sender, Sanmina
>>>> Corporation (or any of its subsidiaries), or any other person or entity.
>>>>
>>>
>> CONFIDENTIALITY
>> This e-mail message and any attachments thereto, is intended only for use
>> by the addressee(s) named herein and may contain legally privileged and/or
>> confidential information. If you are not the intended recipient of this
>> e-mail message, you are hereby notified that any dissemination,
>> distribution or copying of this e-mail message, and any attachments
>> thereto, is strictly prohibited. If you have received this e-mail message
>> in error, please immediately notify the sender and permanently delete the
>> original and any copies of this email and any prints thereof.
>> ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS E-MAIL IS
>> NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the Uniform
>> Electronic Transactions Act or the applicability of any other law of
>> similar substance and effect, absent an express statement to the contrary
>> hereinabove, this e-mail message its contents, and any attachments hereto
>> are not intended to represent an offer or acceptance to enter into a
>> contract and are not otherwise intended to bind the sender, Sanmina
>> Corporation (or any of its subsidiaries), or any other person or entity.
>>
>
--
CONFIDENTIALITY
This e-mail message and any attachments thereto, is
intended only for use by the addressee(s) named herein and may contain
legally privileged and/or confidential information. If you are not the
intended recipient of this e-mail message, you are hereby notified that any
dissemination, distribution or copying of this e-mail message, and any
attachments thereto, is strictly prohibited. If you have received this
e-mail message in error, please immediately notify the sender and
permanently delete the original and any copies of this email and any prints
thereof.
ABSENT AN EXPRESS STATEMENT TO THE CONTRARY HEREINABOVE, THIS
E-MAIL IS NOT INTENDED AS A SUBSTITUTE FOR A WRITING. Notwithstanding the
Uniform Electronic Transactions Act or the applicability of any other law
of similar substance and effect, absent an express statement to the
contrary hereinabove, this e-mail message its contents, and any attachments
hereto are not intended to represent an offer or acceptance to enter into a
contract and are not otherwise intended to bind the sender, Sanmina
Corporation (or any of its subsidiaries), or any other person or entity.
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx
