And welcome back now into this video we'll be discussing about the crosscurrent air strikes is now in
a lot of organizations.
There are requirements that certain blogs are centralized.
And one of the services where the blogs are generally centralized into is a history book.
So let's assume that there are three Atabay second account.
Are going to be in a currency now, in account being a currency.
You have multiple instances of your production that are running now.
As part of the complaint, you have a requirement that all of the logs that are part of the U.S. two
instance need to be stored for the next seven years.
So where you will store that now?
One option is either you will create a history book, it can be stored.
The logs in that history book it again, create a certificate in a currency store, all the logs in
the account to it and so on.
Now, this will work, but it is not really scalable.
Nowadays, organizations have hundreds of accounts and this approach of creating a free market in a
local Idalis account is not the best approach.
So what you will do, the better architected is you have a central account, which is the account area.
You create a three bucket here and all the logs from all of the other accounts can be stored into this
central S3 bucket.
Now, do not that these logs can also include logs of other services like cloud trail, cloud watch,
application logs, system logs and so on.
Now, generally, what happens in enterprises is that when you have a S.A.M. solutions that detect security
attacks and so on, these S.A.M. systems are not directly connected to individual accounts.
They are connected to the S3 bucket of a central account and from a three bucket different all of the
required logs from all of the other accounts that are available as part of the organization.
Now, in order to achieve this, you need to create a three bucket that allows access from multiple
different accounts.
And how to do that is something that we'll be discussing in today's with.
You know, whenever you are designing across Account S3 bucket access, the recommended approach is
to create a bucket policy.
So what will happen is we are taking to account for simplicity.
So you have Al-Ghamdi, which is the central account, and you have the account B, which has the easy
two instances of the production environment that are running.
So what you want you want the account B to store the data into the three bucket of the accounting.
So the recommended way is you create a new bucket policy and that bucket policy, what it states, it
states allow Account B to push logs to decentralised the bucket.
So once you associate this bucket policy to the centralistic bucket, then this bucket will go ahead
and allow the logs to be pushed, considering that they are coming from account B, so this is a very
high level overview.
Now let's look into how exactly this bucket policy looks.
So this is the simple screenshot of a bucket policy.
Now, if you will see in this bucket policy action, there are three actions that are allowed.
You have to object, put object and put object is.
So basically what you want is you want the account to be to push the data, to centralize the bucket.
You do not really want various things like delete operation either.
Otherwise what will happen is let's say one of the you see two instance in action with compromised attacker
can essentially delete all of the data from the same bucket.
So specifically, whenever you're designing a cross account, a three bucket policy, it is very important
to allow only minimal required actions.
This is very important.
All right.
So action is great object put object and put objects here.
This is fine for the time.
We are now in deep principle.
This is a very important part.
You're specifying the area of the account B, so you have the account number followed by the route.
So in such cases, any user in the account B or any i.e. embroiled with India can be considering right
policy said to them they'll be able to perform these three operations on the resource, which is the
central Strathbogie order.
So this is the basic bucket policy.
So let's do one thing.
Let's go ahead and try both, which will be discussing things in more detail.
So similar to the architecture that we were discussing for today's demo, we will have two accounts.
You have accounts and account B now in my Chrome browser, I have a county, so we'll consider this
as our county.
And I have one more account, which is part of my Firefox browser, and we will consider it as it are
going to be.
So at the end of the video, we should be able to push the logs from Account B to account A centralized
ribcage.
So first, let's go ahead and create the centralistic budget.
So within my Chrome browser, let's go ahead and create a new.
Let's call it is my Gabey Labs hyphen Central once, then let's go ahead and create a perfect Solares
three bucket is created.
Now, if you look into the permissions here, let's go back down.
So within the bucket policy, as of now, you see you do not really have any bucket policy.
So that means the other accounts will not be able to push their data to central booking.
So what we need is we want a bucket policy to be enabled here.
So let's do one thing.
Let's go ahead and add a bucket policy.
So we didn't matter how central is three bucket policy that we have available and we have already discussed
about it.
So you have three actions and within the resource you have the name of the three bucket.
Now, one important part that we are discussing is that you need to add your account number of the account
that will be pushing the locks to this extra bucket where this policy is associated with.
So from my Firefox's, let me go ahead and copy the account number of are going to be and I'll be state
auditor once.
Then let's copy the bucket policy and let me be straight with you.
So this is how it looks like.
Let's go ahead and save the change.
Perfect.
So are a three bucket policy successfully added?
Great.
So our first part is completed.
Now the second part is related to the accountably configuration.
Now, for this example, we had made use of two instances, but it can also be a Amusa.
Let's say I am a user of account B wants to upload some critical data center list at the end user should
also be able to do that.
So for today's video, we'll go ahead and create a new AYAM user for the test purposes.
So let's quickly go to the end service from the account B
and within.
Let's go ahead and create a new user just for simplicity.
We'll just call this.
Users are going to be will give the user a programmatic access permissions.
Let us avoid as of now and we'll go ahead and create the user.
Perfect.
Now just for simplicity of our testing purpose, I have easy doing stance with Amazon Linux too.
And within this easy doing, since I create a new user and a user name, lezzies qualities are going
to be Orleck and we'll go ahead and switch the user to account B and within this user will associate
the Access Kadian Secret Access.
So let's see dabblers configure.
I'll add the access key.
Let's keep it a secret access key and the region name.
Let's just use the default region of USD two and even our bucket is created near perfect.
So our account is associated with the established credentials.
At this stage, when you do a estriol you should see the access they need, primarily because you do
not really have any IAM policy associated with this account.
Now the second important part of this architecture is that the IBM entity, maybe I am user or Ambro,
must also have a permission to push the data to centralize rebudget.
It's not like you have allowed the bucket policy in centralized Rivergate and all of the IAM entities
in the account.
We will be able to do that.
The policy also needs to be associated with the amended account.
So what we need to do is we have to create a new IAM policy for the IAM user that we have created and
are going to be.
And what this policy allows us to do.
Again, the reactions get object, put object and put object is here and here we are specifying, decentralised,
working on it.
So I hope you understood the importance of the acronym policy.
So we'll go ahead and copy this and policy here and will associate this IAM policy with the account
to be Amusa.
So let's open the user here.
Let's add a new inline policy will go to Jason.
I based the policy here.
Let's do a review policy and the name Liz's escalator's cross account is three will go ahead and create
a policy.
Perfect.
So now all the necessary configuration for account and achonwa is completed.
So let's test things out.
So what I do, I'll first upload some sample data to the attribute bucket of accounting.
So this is something that we can directly do from the console itself.
Let's do that.
I define the file.
You can just add any temporary file that you have within your system.
Perfect.
So the file is added in the central bucket.
Now, since within the bucket policy we have allowed the gate object, that basically means the immensity
of the account.
We should be able to fetch the data from history.
So from the account be let's try it out.
I'll say the place is three.
Try to copy the data, which is to pay for DataDot, and the budget is likely to be less central and
will be the contents here.
And you see the download operation is working perfectly well.
So if I do a little area, we have to pay for DataDot.
These so things are working as expected.
Similarly, let's also try to upload some data from you.
So let's create a new file, I'll call it as account B dot text and let's try to copy this file as three
strict account B, and we want to piece it to my left hyphen center.
And you see upload also is working perfectly well.
So now if I refresh the page here, you should see you have accounted for and dot also available.
Great.
So I hope with this you understood at a high level overview about the workflow behind Corozal content
success.
But at this stage we are not yet done.
That is one very important part that also needs to be looked into.
We'll be discussing about that in great detail in the upcoming video.
But I'll just give you a just about the problem that you will face in this architecture.
Now, what has happened is both of these files are part of this bucket, but the permissions that are
associated with both of these files are completely different.
Let's quickly look into it now for the account.
Be dirty whenever I go ahead and try to download this file.
You see, I am getting access denied message.
Very interesting in a similar way, the files that have uploaded from the account itself.
When I try to download that file, let's try to do that.
You see, the file download is working perfectly.
So the primary reason why this is not working is that this file account funded or B is associated with
the account B and the next file to pay for DataDot is associated with the account A now, although I
have an administrative access in account E, this does not mean that I have permissions or files that
were uploaded from the account to be so will be discussing about this in great detail.
But it is very important to know that if you're implementing it in production environment, I have seen
this issue where there are multiple teams collaborating in a central S3 bucket and the other team is
uploading all of their data in hundreds of gigabytes.
And later they realize that all of the data that was uploaded to the central S3 bucket, none of the
users from our county was able to access it.
So this was a bit of a pain and will be discussing on why this happens and the best way to resolve this.
So with this will conclude today's video.