Amazon AWS Certified SysOps Administrator Associate – S3 Storage and Data Management – For SysOps Part 9

26. S3 Access Points

Okay, so now let’s talk about s three access points. And to make it easier, I will start with a diagram. So let’s say we have a bucket and in this bucket we have different folders. For example, we have a finance folder, we have a sales folder and so on. And so we know that we can restrict access to different folders based on a bucket policy. And so the bucket policy can be quite simple. But as soon as we have more users and more groups, for example the finance group, the sales group, and the analytics group, it can become quite complicated to regulate who can access to what. And the bucket policy can get really, really big. So the solution to that is to create access points.

So access points can be defined exiled outside of your bucket and the access points are going to be linked to a specific part of your bucket. For example, the finance access point will give access only to the finance data in the finance folder and the sales access point is going to give access only to the sales data in the sales folder. And the analytics access point that you create as well could have access to both these folders because analytics people need to analyze all this data at once. So the idea is now the finance user group has access directly only to the finance access point and through the finance access point will get read write access to the finance data.

The sales access point group will be given access to the sales access points again, and with a specific policy will get access for read write to the sales data. And this time the analytics team will only get read access to all the buckets through their own analytics access points, which makes sense. So each access point will have its own DNS. Okay, so the bucket will not be accessed through the normal DNS of the Svocet, but through its own DNS of the access point.

And there will be a policy with each access point to limit who can access this access point. So it could be a specific im or user group and it could be one policy per access point. That means it’s going to be a lot easier to manage than complex bucket policies. So without the access points, you have a master bucket policy with all the rules written in it. But with access points, each access point will have its own bucket policy.

So it becomes way easier to make sense of who can do what. You can also restrict traffic from a specific VPC on each access point for private access. And the access points are going to be linked to a unique specific bucket, which is a unique name per account region. Okay, so let’s have a look at how access points work in the console. So let’s go ahead and create an access point. And for this, on the left hand side, I have the Access Point direct menu and in here I can create an access point. So calling this one demo Access Point and then you have to specify a bucket name so I can specify the demo S Three event Stefan. In my bucket the region is determined by my bucket location.

So EU West One and then the network origin for this access point. So is this a VPC access or is this an internet access? Now if you specify the VPC access that means that you want all the traffic to be coming from within your VPC so you want it to remain private. In which case, while the S Three console doesn’t support accessing, the S Three bucket resource using the VPC access points and you need to use the API. If you specify VPC, you need to obviously specify a VPC ID. But I want to demo stuff to you. So I will use the internet, and in the Internet I will be able to access my access point publicly.

Next, do we want to block public access settings for this access point? So we have the same setting as your S Three buckets and then the Access Point policy which is written in JSON and will provide access to the object stored. So let’s look at some examples for policies for access points. So let’s say we want to ensure that this bucket name right here is only accessed through an access point policy and it will only give access to a subfolder. So for this I can go into the policies example and it will scroll down. So I will click on Access Point Policies examples and then I will show you the first step. So the first step is to create an Access Point policy grant and so I’m going to copy this and paste it.

And if we look at the statements so we allow a specific user, for example, I can take my account ID in here and say the user Stefan is only going to be able to do get Object and put Object on and then I need to specify the proper region. So it’s EU West one. The account ID again is here access Points. Okay, and here is the name of the access point I have. So let’s just copy this name right here and call it to my access points access point name and then object Stefan star. So this is going to only allow me to write to the directory Stephan star, which is I think pretty cool. And so this is the Access points policy. So now it’s been applied and I can access this access point right here. And as you can see it took me directly into the demo as Christyfund buckets and created an access point as well in here.

So my access point is now linked to my buckets and what I can do is that I can go now to my bucket’s permissions and change the bucket policy. Why? Well, because we’ve created an access point in here. And that means that if we access RSP buckets through this access point and my staff and user access it through this access point, then it’s only going to be allowed to access a specific sub directory. But my users define could still access my bucket through the buckets directly. So what I need to do is go into permissions and create a bucket policy that will be blocking any access other than access points. And to do so, you click on Delegating access control to access points and then you need to paste that bucket policy in. So let’s do it. I will edit this bucket policy and paste it.

And in this example we’re saying, okay, allow any win any action on the bucket ARN. So we need to get the bucket ARN right here. So the resource is this one and then this one star, okay, as long as the access point account is using the bucket account ID. So here it is. I’m going to paste this in. So effectively what we’re saying is that this extra bucket can only be accessed if you are using an access point coming from this account. And this is the current accounts.

So this is good because now what we’re doing is that we’re saying, hey, you can only access this bucket through the access points. And now you can define as many access points as you want directly in here. So I’ve created one, but I could create another one. And then through the access points, as you can see, we can view the buckets and so on. And there’s going to be a specific ARN for this access point. So that’s it for this lecture. We’ve seen access points in detail. I hope you liked it and I will see you in the next lecture.

27. S3 VPC Endpoints

So here is a short theory lecture. But this is important for you to understand how the VPC endpoint gateways work for Amazon is free. So by default an Svocet lives on the AOS cloud, okay? But to access it you need to go through the public internet. So that means that your instance launch in a public subnet, for example, will access through the internet gateway the public endpoint of your SBR bucket and the file files go that way. That means that your svocet can have a bucket policy and you can filter by a resource force IP to be a public IP of your EC two instance, okay? Now if you wanted to have a private access to your SV bucket, so you don’t want the traffic to go through the public internet, then you deploy your instances, for example in a private subnet and you would create a VPC endpoint gateway.

So this VPC endpoint gateway allows you to establish a private connection from your instance directly into the Aster buckets and this allows you to create different bucket policies. So this one the bucket policy you can apply to force access only through a VPC endpoint gateway is to use a bucket policy by AWS source vpce and you can specify one or few endpoints or you can specify a bucket policy and specify a source VPC condition to income pass all possible VPC endpoints within a predefined VPC. So that’s it just for you to show you the two different ways. And obviously the VPC endpoint gateway is going to be preferred for security and also I think for cost reasons. So that’s it for this lecture, I hope you liked it and I will see you in the next lecture.

28. S3 Bucket Policies Advanced

So, here are some examples of S Three Bucket Policy that are advanced and you don’t need to know them going to the exam just to know that the possibility does exist. So, you can use an S Three Bucket policy to grant public access to the Buckets, force Amgex to be encrypted, and upload, grants access to another account using cross accounts. And you can specify conditions on public IP or Elastic IP, but not on private IP, the source VPC or Source VPC Endpoint. And this works only with VPC endpoints, the cloud front origin identity.

So, if you want the traffic to just come from cloud front MFA, if you want multifactor authentication to be present, and you can find a lot of examples here, and I invite you to have a look at it in your own time. Okay, so if we have a look at some of them that I think are very valuable, here’s an example. So, this one is restricting access to an instrument bucket to all principles as long as they belong to an AWS organization.

So the idea here is that if your account is part of an organization, it will have access to this bucket, which is a scalable way of doing cross account access across an organization. And to do so, well, it’s a condition, and you specify the AWS Principal. org ID condition key to be done with it. This one policy prevents upload of unencrypted objects. So you force objects to have an Xamz service head encryption. True. And to make sure that this header is present.

So this is a very common one to deny any upload of unencrypted objects. This one is to restrict IP addresses. So you’re saying that if the IP is not in the range that you’ve provided in the condition, then deny and upload. So this one is an example of the Not IP Address Condition key. This one is to show that a user can list and download objects in an extra bucket. But as you can see, and this is very important, the list bucket property is applied to the Resource ARN without a slash because it supplies to the bucket itself. Okay? But the get object applies to the objects within the bucket.

So the Resource ARN applied to it is the full object, the full Resource N A Star. This Bucket policy is making sure that you do get objects only if you have been authenticated and you’re doing multifactor authentication. So the condition here is multifactor of Present. True. Okay? So just make sure you have a look at these policies, make sure you understand their use cases and how they’re formed. The important stuff to know out of it is that conditions allow you to create very, very complex conditions for your Sree bucket policies. So, that’s it for this lecture. I hope you liked it, and I will see you in the next lecture.

• Category: Uncategorized