Red Hat OpenShift Red Hat OpenShift on AWS (ROSA) | Red Hat OpenShift, 13 Sep 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: Red Hat OpenShift Service on AWS (ROSA): IAM roles for service accounts to connect to RDS

Description

In this video, we will show a modern and secure approach to connect a ROSA cluster to an Amazon database using IAM Roles for Service accounts following the AWS Well-Architected Framework.

A

Hi I'm Michael, McNeil and I'm, a member of our managed openshift black belt team here at Red Hat I'm here with my colleague, Kevin hi,.

B

I'm Kevin Collins also a member of the managed openshift black belt team. So today we're going to talk about IM rules for service accounts, it's also known as pod identity. This will show you how you can create a secure connection from your Rosa cluster to a database like dynamodb, RDS, Aurora, or anything like that. So.

A

Tell me why I would want to use this as opposed to just using static credentials. I mean I could just use an iamt or something like that. What's really the benefit of using irsa yeah.

B

There's several reasons: why there's also the using irsa files, the AWS, well architected framework or creating a trust policy between our pod? That's running our application and dynamodb, and it's going to use short-term credentials they're going to rotate each time we call into dynamodb. So it provides a more secure and much more granular connection to the database as we're going to go through today. Awesome.

A

Well, how does.

B

It really work yeah, so it works by starting at Rosa. If we're going to first create a service account and like this is nothing new for all openshift applications that need special permissions. We recommend use the service account to run the application. So after we have the service account, we'll put a number one there that we need to set up a couple of things in IM. First thing: we're going to do is create a policy and I am policy and and AWS and the first thing the policy contains several things.

B

One is a principal and the principal says who can do which action action? The person that's going to take the action on our behalf? Is this oidc provider says IDC provider with a Rosa cluster. We get this by default when we create the cluster, so the oidc providers provides short-term credentials for pods running in in the cluster. So, for example, there's many parts of of Rosa, one is say. The image registry right limits. Registry needs permissions to do certain things, namely needs to access S3 to store the images.

B

So if s3d or if the registry needs to access X3 S3 to store images, it doesn't need to do things like speedometer ec2 instances, so using short-term credentials with oedc provider. We're able to give the Pod side control the registry permissions to only connect to S3 and Nadu thinks it doesn't need to do like spit up ec2 instances.

B

So we're going to use the same principle here, uh it'll create a new policy and it's going to be the IDC provider. It's going to perform the action on our behalf. Also in the policy. We have an action well, in this case, we're going to have assume for all so we're gonna. Let the oicdc provider assume we're all that we're going to create in a minute, and then we have. uh What can it do so there's an effect.

B

And this typically would be allow or deny so in this case we want to allow the IDC provider to assume a role, and last thing we have is a condition. So a condition says: are there any special circumstances on when this should occur and we're going to add one that says the service account if the service count is the one that requested it, then this can be done. Also.

B

What this is going to do is to create a trust policy with a role we're going to create a new role. So this two we create that policy. Then we create a row we'll call it like my ad DB roll B, whatever name you want, obviously, and then we assign this policy to that role. So at this point we have a policy, that's the IDC provider, assume they're all in create SCS credentials, but we don't. We haven't given access to anything yet, which is the next step.

B

We create another policy, we don't create the policy we attach a policy So within AWS like Dyno DB is an example. They have a lot of pre-built policies, so we can create our own or use something that comes with AWS and they have one called AWS Dynamo do some shorthand here there's one called Full Access so assign this policy to that for all, and then this completes the the IM portion of this awesome.

A

So I understand this, but I'm confused. How does the like service account actually know anything about? What's going on at AWS, IAM great.

B

Question so when we create the service account, we create an annotation.

B

And the sanitation says you know we're going to do some additional permissions here and we're going to set the ODC provider and the role to be uh called when, when the service account needs to access, Dynamo DB got.

A

It so The annotation says that the role is this, so it knows what to do. But how does this all work behind the scenes, because an annotation really doesn't actually do anything to the pod? That's running right.

B

So that's the next step, so uh so first we described this- is all a user asks you to set this up, but the way it works in the back end is when, when you we have an application, just create a pod here.

B

So the cloud is created initially there's something called the pod identity, I'll shorthand webhook.

B

And this web Hook is listening for a different events. So in the Pod starts it says: hey, there's a annotation on the source account I need to go, uh go to the provider, that's in The annotation, which is the IDC provider and I need to get a token, because I know I'm going to be requested later to perform some action, so the Pod identity, Web book, returns that there- and this is a Json web token. So the IDC provider provides that token stores it in the Pod awesome.

A

So once we do all that right, how do you go about changing the permissions of this role, so I I don't want to give it full access. Aws says: I need to have least privilege what what do I do to reduce the scope of that role. You.

B

Simply would change this role, so you can remove the full access policy. You could do something like read only as an example.

A

Oh, that seems a lot easier to just reduce policy. So there's nothing else. I have to change here. I just simply change the policy at AWS, and then it changes the permission. That's right! Awesome! That's great! Well, thanks! So much for taking the time to watch this video. If you have more information, if you have more questions um or or looking for more information on red hat products and services feel free to visit our website at www.redhat.com.

A