 Okay, morning everyone, welcome to our first talk in the software defined storage deaf room. Put your hands together for Preta and enjoy. So, yeah, a very good morning to everyone here. My name is Pritha and I'm a software developer with Red Hat. I've been working with the Rado Skateway team for the last three and a half years now and today I'll be presenting a talk on secure token services. So, these are the topics that I have in line for today. I'll be giving a brief introduction on what deaf and deaf object gateway is and then I'll touch briefly upon what AWS STS is and then the remainder of my talk is going to be around what has been done in deaf object gateway to support STS. So, moving on, what is deaf? So, deaf as we all know is an open source, highly scalable object storage which provides unified interfaces for block, file and object storage. What is deaf object gateway? So, a deaf object gateway is also known as Rado Skateway or IGW and it provides an HTTP restful interface for accessing the object storage cluster and it also provides interfaces which is compatible with a large subset of AWS S3 and Swift APIs. So, moving on to what AWS STS is. So, AWS STS is a web service that provides temporary credentials to a user when a user requests for it. So, we all know that whenever we want to access S3 resources in AWS we need to have permanent credentials at hand but AWS also provides an alternative method of getting back some temporary credentials to access the same S3 resources. So, the talk is mainly going to be about what we have done in deaf object gateway to support STS. So, moving on, so in RGW now we provide support for a subset of STS APIs mostly for cross-account access and web identity federation and in order to support STS there are certain basic building blocks of IAM known as IAM roles and IAM policies and now in RGW we also provide implementation for a subset of those APIs especially related to IAM roles and IAM policies. So, I will be covering these two concepts going forward a little bit and since now RGW has the mechanism of returning temporary credentials to the end user we also support mechanisms to authenticate them which involves taking into account some extra STTP headers like the XAMZ security token and things like that and all the APIs the STS API the IAM API and the S3 API they all exist in the same namespace and the STS has been released as part of Nautilus which was released sometime back. So, what are temporary credentials? So, permanent credentials in order to access S3 resources are a pair of access key ID and secret access key. So, temporary credentials in addition to these two parameters also include something known as a session token. So, what does session token include? So, whenever any STS API is invoked in the RGW it returns temporary credentials back to the end user and it includes the access key ID the secret key and also a session token. So, the session token is encrypted and therefore it is opaque to the end user but it contains a lot of useful information for RGW. Whenever a user calls any S3 or makes any S3 call using these temporary credentials the RGW extracts authentication and authorization information from the session token. So, the authentication information again includes the access key ID and the secret access key using which it does all the V4 and V2 signature validation and it also has the authorization information which consists of the permission policies that are attached to the roles and these permission policies determine what kind of activities or what kind of S3 operations the end user can actually perform. So, moving on to what a role is. So, like I said before role is a very important concept as far as STS is concerned. So, a role is an entity very similar to a user but it can be assumed by multiple users. A role has two kind of policies attached to it. One is known as the trust policy and the other one is known as the permission policy. So, a trust policy defines what users are allowed to assume the role and if we want multiple users to be assuming the same role then in that case the principal element can be an array of all the users which will be allowed to assume that role and the next is the permission policy that is attached to a role which defines what a role is allowed or is not allowed to do. So, in the permission policy we can specify what actions can be allowed and whether the action is allowed or it is not allowed and currently we provide support only for inline permission policies which are embedded in the role and we do not provide support for managed policies or independent policies as of now. So, now I will be talking about a couple of STS APIs that have been implemented in RGW. So, the first one is the assume role API and the assume role API is mainly for providing cross account access to users. So, let us say we have two users one is user A and the other one is user B and user B has some buckets which user A wants to access temporarily. So, in this case we can create a role R and attach a policy to it which will allow access to the buckets of user B and then user A can simply assume the role R and get back a set of temporary credentials and it can start accessing user B's bucket going forward. The next API is assume role with web identity. So, this API is mostly for any kind of external application that wants to access S3 resources and it can do so without owning any kind of permanent credentials. The main part here is that the external app should be able to authenticate its users with any external open ID connect or OAuth 2 compliant IDP. And currently in RGW we have provided support for key cloak. We are looking into other IDPs but right now it is only integrated with key cloak. So, this is a simple example of what assume role with web identity can do. All the users in the external app can authenticate with key cloak. Key cloak will return back a web token which can be an open ID connect access token or an ID token and then the ID token can be used to invoke the assume role with web identity call in RGW which will return temporary credentials. And then the external application can make S3 calls using those temporary credentials. And in this case when we are invoking assume role with web identity we do not need any kind of permanent credentials. We simply have to use the web token returned by key cloak and we can get back credentials to make S3 calls further. So, what are the advantages of these kind of credentials? The advantage here is that the credentials are temporary in nature and they will automatically expire after some time. And since we have the concept of permission policies attached to role and STS APIs we can control what kind of permissions we want to attach to these credentials so that the end user need not have access to all S3 resources or all kind of S3 operations on the S3 resources that are available to it. And these credentials are not persistent in RGW. So, we do not need to have a mechanism in which once the credentials expire we go and check what credentials have expired and then we go and delete it. So, this overhead is not there. So, that credentials are returned back as part of the STS APIs and the end users simply make use of them and make S3 calls. They are nowhere stored in the RGW or the rados. So, there is a mechanism of restricting permissions further in using these STS APIs. So, what a role can do is it can have permission policies which are very generic to any kind of users that may want to assume a role. But each of the STS APIs also have a provision of taking in an IM policy which can restrict the policies further. So, the resultant permission policy is an intersection of the policy which is attached to the role and also which is passed as part of the STS APIs. So, as for example, a role can have a policy which allows all kinds of S3 operations like this. But an end user who is trying to assume the role may not want it or we may not want to provide the end user to be able to perform all kinds of S3 operations. So, in that case, we can restrict the action like this. Like in this example, it is listed as S3 list all my buckets. So, whenever this user tries to perform any other kind of S3 operations, it will be denied according to this permission policy. So, in RGW, we have also extended the concept of STS to something known as STS light. We have several kinds of authentication mechanisms. The main ones being the local authentication mechanism and the external authentication mechanism. So, in case of local authentication mechanism, we authenticate all the incoming requests internally by calculating the V4 or the V2 signatures. But in case of external authentication mechanisms, all S3 calls have to be routed to any external IDP which will make sure of the authentication part. So, this introduces a lot of latency in authenticating any S3 call and also sometimes overloads the external IDP. So, the idea here is that to use one of the STS APIs known as get session token and come up with a solution for reducing the latency. So, what the client does? It will first invoke the get session token in RGW and this call will actually authenticate with the external IDP. And once the authentication is successful, it will return a set of temporary credentials to the end user and then the end user will make all subsequent calls using these temporary credentials where the authentication is going to happen internally. So, using this mechanism, the latency and those other kinds of issues have been solved for external authentication mechanisms. So, STS Lite has mainly been implemented for Keystone. Keystone was the main use case where we saw that this could help but it also works for LDAP and it also works for local authentication. And there are lots of other things that are still left to be done with STS. One is the assume role with SAML call and then we need to look at other open ID connect and OAuth2 compliant IDPs which will work with RGW. And currently we are looking at supporting MFA with the STS APIs. And there is an STS key which is used to encrypt the session token. So, that also needs a lot of improvement. Currently it is just an ASCII string but we need to look at providing binary and other kinds of keys that will be helpful in encrypting the session token. So, these are the links for the documentation to STS Lite and role and time for questions. Wait a second. Does the mic work? Right. Very good. Are there any plans to integrate with SAML protocol of single sign-on like Shibolet, Symposam, PHP? Yeah, we are looking at that at the moment. Thank you. Especially, yeah, assume role with SAML. You mean assume role with SAML, right? Yeah. That's ongoing work. Any more questions? Thank you.