rgw: Add External Authentication for S3 #34093
Conversation
Signed-off-by: Seena Fallah <seenafallah@gmail.com>
Signed-off-by: Seena Fallah <seenafallah@gmail.com>
Signed-off-by: Seena Fallah <seenafallah@gmail.com>
Signed-off-by: Seena Fallah <seenafallah@gmail.com>
S3 can authenticate users with custom authentication servers based on needed APIs. Signed-off-by: Seena Fallah <seenafallah@gmail.com>
clwluvw
force-pushed
the
external-authentication
branch
5 times, most recently
from
77f0bc1
to
cfffedf
Compare
|
Well, currently remote authentication works fine, but creates a shadow user--not in keystone, but in the RGW database. That can then be a system user, have caps, and so on. I will read further. |
|
@mattbenjamin Really thanks for your attention. Yes in this scenario we have a shadow of external users in RGW database. The main point here is to support SubUser and Permissions and admin users that still are shadows and it acts like Keystone integration. |
clwluvw
force-pushed
the
external-authentication
branch
4 times, most recently
from
56d58ae
to
52b6030
Compare
clwluvw
force-pushed
the
external-authentication
branch
4 times, most recently
from
592587b
to
ab16410
Compare
Signed-off-by: Seena Fallah <seenafallah@gmail.com>
clwluvw
force-pushed
the
external-authentication
branch
from
ab16410
to
2ea0a64
Compare
|
jenkins render docs |
|
Doc render available at http://docs.ceph.com/ceph-prs/34093/ |
|
@mdw-at-linuxbox It's now ready for your review :) |
|
@mattbenjamin Hi Matt. Can someone else review this PR? |
|
why is it necessary or useful to invent a new authentication protocol here? |
@cbodley To support subuser and other RGWUser features in Remote Authentication. And also anyone have it's own authentication server (Organizations most have) by implementing these APIs. |
these are radosgw internals - it's not clear why they should be involved in remote authentication
most organizations don't write a custom json endpoint to handle their authentication, they rely on integration with existing services though keystone, ldap, or sts |
Hi @frittentheke, I'm confused; This discussion was about subusers, which is, in part, a mechanism used with Swift interop when the users are RGW local users. RGW (separately) has keystone integration, which permits authentication directly as OpenStack users. What am I missing? |
Yeah @mattbenjamin sorry my statement was indeed confusing. I was referring to support for OpenStack Keystone "users" as subusers for buckets. Currently RGW only uses the the
This actually renders bucket policies with rules for different Keystone users non-functional as they are all reduced to their project. I once asked on the ML about this as well https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/message/S2TV7GVFJTWPYA6NVRXDL2JXYUIQGMIN/ and I simply thought a generic implementation for external authentication could enable such a richer integration as it apparently also has support for subusers. |
|
@mattbenjamin would you kindly take another look at this PR or even my question on the ML (https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/message/S2TV7GVFJTWPYA6NVRXDL2JXYUIQGMIN/) about the keystone auth integration? I am just so darn confused that currently only the project id is taken from Keystone which is then rendering all nice features such as Ceph subusers or any further access control useless. Are you potentially working on extending the integration in #43898 ? |
| users with all RGW User features like SubUser, Tenant, Permissions. | ||
| The only thing you should obey is to implement these APIs so we can get needed | ||
| data from your sever. | ||
|
|
There was a problem hiding this comment.
Suggest something like
It is possible to use an external authentication server for the Ceph Object Gateway (RGW), providing
all user features including subuser, tenant, and permissions. The external server must implement that API as below.
| External Authentication APIs | ||
| ============================ | ||
|
|
||
| In your authentication server you should implement these APIs so we can get our needed data |
There was a problem hiding this comment.
s/In your/The/
s/you//
s/our//
| } | ||
| } | ||
|
|
||
| ``access_key_id``: This is a access key which is used in request. |
There was a problem hiding this comment.
Maybe something like
This is the access key used in requests
This is the request signature computed with the user secret / signing key.
| ``user_id``: user id for RGW User | ||
|
|
||
| ``tenant``: Optional. If user has tenant. | ||
|
|
There was a problem hiding this comment.
Optional, only needed if the user has tenants.
|
|
||
| ``tenant``: Optional. If user has tenant. | ||
|
|
||
| ``user_name``: display name in RGW User |
There was a problem hiding this comment.
RGW user display name
| .set_default("") | ||
| .set_description("URL to external authentication server to get user secret") | ||
| .set_long_description( | ||
| "To cache user access key and secret key we use to send GET request to this URL" |
| .set_description("URL to external authentication server to get user secret") | ||
| .set_long_description( | ||
| "To cache user access key and secret key we use to send GET request to this URL" | ||
| "in pattern of URL/?access_key_id=ACCESS_KEY_ID and need response in format of" |
There was a problem hiding this comment.
In the pattern of
and need a response in the format
| .set_default(10000) | ||
| .set_description("external authentication access key cache size") | ||
| .set_long_description( | ||
| "Max number of access keys that will be cached. Access Key that is not cached " |
There was a problem hiding this comment.
Access keys that are not cached require the
|
|
||
| Option("rgw_s3_external_authentication_verify_ssl", Option::TYPE_BOOL, Option::LEVEL_ADVANCED) | ||
| .set_default(true) | ||
| .set_description("Should RGW verify the external authentication server SSL certificate."), |
There was a problem hiding this comment.
.set_description("Should RGW verify the external authentication server's SSL certificate?"),
|
|
||
| Option("rgw_s3_auth_use_external_authentication", Option::TYPE_BOOL, Option::LEVEL_ADVANCED) | ||
| .set_default(false) | ||
| .set_description("Should external authentication be used to authenticate users."), |
|
I don't know if we should be doing what this PR intends, but it seems to be doing several things. I'm most suspicious of "remote authentication for S3." RGW already has Keystone authentication. I think the oldest part of this change involves changing the Keystone integration, so we also need to fully understand that. But what sort of remote authentication protocol standard does the "remote authentication for S3 " represent? Why can't integration with established OpenID::connect- and Oauth2-enabled IDPs satisfy the requirement, esp. given their intrinsic support for dynamic authz of different kinds? |
|
@mattbenjamin Well, the idea was to have a general rest API for external authentication. In this case, it won't be limited to any authentication systems (like keystone, ...) and on the server-side (authentication server) anyone can have its own implementation and prepare the APIs needed by RGW to sync and could use all the RGW User's feature! |
It would be my contention that it's not consistent with RGW's role to define a sui generis remote authentication protocol. To repeat a question from above, why is it not possible to build on OpenID::connect() or Oauth2--these are established standards with a lot of flexibility and basically well-known security properties? |
I second your thinking here. While looking at OIDC or SAML to allow RGW to consume an existing authentication setup one cannot ignore that OpenStack Keystone is quite a common auth target for RGW, but it currently does not provide those kind of "standard" interfaces. The federation feature (https://docs.openstack.org/keystone/latest/admin/federation/introduction.html) works to integrate Keystone with existing authentication systems. And if those exists in the form of a versatile implementation like Keycloak those could then also be used as auth source by RGW. But, with only Keystone and it's built-in auth, which is natively supported by RGW the case looks different. Also the question is if the proper claims and metadata can be provided to a potential client RGW yet. So enabling features like subusers, groups and whatever RGW supports to use in its bucket policies. Also the mapping from and to the world of EC2 credentials to serve S3 adds some more complexity. What I am saying is that just having a standard and very common auth protocol like OAuth 2.0, only helps if that's what your clients use. If you "only" want to integrate one established system like Keystone or the whole of OpenStack services with RGW, RGW might have to have a more plug and play integration into that ecosystem. And while that exists in the form of keystone_auth (which lacks in functionality, see #34093 (comment)), it's reasonable to think about having a more generic integration available which then allows for a simple far end to exist on the Keystone side. If you allow for a comparison, look at what Kubernetes does with its webhook auth: https://kubernetes.io/docs/reference/access-authn-authz/webhook/. That also does allow of any arbitrary system to provide auth to Kubernetes, while they certainly also support OIDC ... if you already have that for your clients. |
> > But, with only Keystone and it's built-in auth, which is natively supported by RGW the case looks different. While OAuth 2.0 is being worked on (https://blueprints.launchpad.net/keystone/+spec/oauth2-client-credentials-ext, https://blueprints.launchpad.net/keystone/+spec/enhance-oauth2-interoperability) this is not yet available widespread. > > Also the question is if the proper claims and metadata can be provided to a potential client RGW yet. So enabling features like subusers, groups and whatever RGW supports to use in its bucket policies. Also the mapping from and to the world of EC2 credentials to serve S3 adds some more complexity. > > What I am saying is that just having a standard and very common auth protocol like OAuth 2.0, only helps if that's what your clients use. @frittenthek you're clearly very informed--can you clarify just a bit further what you're actually recommending with respect to the current PR? is there a gap in our keystone support that we need to fill (e.g., exposing subusers), and if so, do you support the subuser change being proposed by @clwluvw ? and am I correct to read you as rejecting the "generic auth protocol" part of this--I'm reading that as your take, in spite of the caveats you mentioned; Please correct me if that's incorrect. thanks! Matt |
Certainly @mattbenjamin . First of all I second your thought of questioning why RGW should support more than the likely most common OIDC + OAuth2 to talk to an external and existing authentication system. It certainly is well established and has lots of flexibility, the issue arises in the case of OpenStack Keystone being the "only" authentication system and it not yet being an OAuth2 authentication server itself. Currently Keystone only provides SAML when serving as an IdP (https://docs.openstack.org/keystone/latest/admin/federation/configure_federation.html#keystone-as-idp). And SAML while also being a standard (even if it's on its way out ...) , does not get us anywhere with RGW. See maybe https://softiron.com/blog/integrating-rados-gateway-with-an-external-oidc-provider/ as an example how an OIDC provider is expected and, getting back to Keystone by itself is not yet capable of providing this. This is being worked on, see https://review.opendev.org/q/topic:bp%252Foauth2-client-credentials-ext, with different integrations than RGW in mind so far though, so I am unsure if this covers everything to work as an OIDC provider to RGW. It's not about authenticating, but providing the right data for authorization. One would much more likely go the path of having something like Keycloak be the hub of all authentication and authorization and doing any sort of data fetching, field mapping and token exchange there. But in a setup where a flexible OIDC provider such as Keycloak exists, both, Keystone and RGW would just be be clients to it. But quintessentially this asks for third component, the commonly used authentication system, to be setup and there is lots of complexity in implementing and integrating this.
Yes there is a (or maybe more) gap. Currently at the very least the lack of sub-users. If you look at my first point of my post to the ML at https://lists.ceph.io/hyperkitty/list/ceph-users@ceph.io/message/S2TV7GVFJTWPYA6NVRXDL2JXYUIQGMIN/ currently only the There already was PR #33210 also by @clwluvw implementing this, but unfortunately this went stale during review 😞 . If Ceph wants to keep and maintain specific integration to Keystone auth, it would be awesome to pick up on that one (again).
No - I was, sorry about the amount of words I used. Having OIDC as generic integration for auth is great and a must have and I also strongly agree to not even attempt to create a similar feature rich protocol. But as said above it's not always applicable to expect only OIDC on the other end, depending on the environment people want to integrate RGW with. Thinking this through this would require at least a first actual use-case, so an integration. Keystone or rather the adapter in fron of the keystone auth could be one. But talking about introducing this generic auth and then deprecating the well established and widely used Keystone auth in RGW in favor of a new piece of software might be too much of a stretch. |
|
This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days. |
|
I don't consider this stale. |
|
@frittentheke It would seem that adding support for AssumeRoleWithSAML, and combining it with keystone-as-idp (SAML) would be a viable option, would it not? |
|
@mmgaggle Sorry about the late response.
This sounds like it's going in the right direction of reusing existing capabilities ....
but is this really lightweight enough to have this as the standard auth integration of RGW to an OpenStack cloud? Could you explain how the config and dataflows would look like then? |
|
This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days. |
|
@mmgaggle would you mind diving into your idea a little more? |
|
This pull request has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs for another 30 days. |
|
This pull request has been automatically closed because there has been no activity for 90 days. Please feel free to reopen this pull request (or open a new one) if the proposed change is still appropriate. Thank you for your contribution! |
Ceph external authenticators like Keystone, LDAP, STS, ... doesn't support all RGWUser features and force users to use Keystone, ... servers and can't use their own authentication servers. With this PR anyone can have their own authentication server (Organizations most have) and Ceph Object Storage (S3) can authenticate users with their own authentication server based on needed APIs. Now Remote Users can have SubUser, Permission, is_admin, ... when they come from the server.
Signed-off-by: Seena Fallah seeenafallah@gmail.com