IAM & Glacier
Just like S3, Amazon Glaciers offers cloud-based storage. It Glacier provides users with a simple, secure, cloud-based data storage that can quickly be scaled up or down as needed. But unlike S3, which is designed to provide users with quick access to their data, Amazon Glacier is designed for the long-term storage of inactive data that will not need to be quickly retrieved. it takes three to five hours for retrieval and therefore because of this long-term, slow-moving method is known as cold storage, hence the name Glacier.
Cold storage is unusual because we focus on price over performance, price over latency, price over bandwidth. It allows even small-scale users to have access to low-cost, off-site, multi-datacentre, cold storage at a cost previously only possible at very high scale. Implementing cold storage centrally in the cloud makes excellent economic sense in that all customers can gain from the volume economics of the aggregate usage.
If you’re looking for low latency data storage and require frequent access to your data, then that’s what S3 is for. If, however, you are looking for something more along the lines of archival file storage, then the price and flexibility offered by Glacier is definitely worth exploring. Glacier’s storage fees are remarkably cheap, starting at just $0.004 per gigabyte per month.
Amazon S3 Glacier offers 3 retrieval options. Expedited Retrievals can fetch data within 1–5 minutes. This property makes it a better option for Active Archive. Standard retrievals typically take 3–5 hours to complete the retrieval.
Also, it works well for less time-sensitive needs such as backup data, media editing or long-term analysis. Bulk retrievals are the lowest-cost retrieval option. With this, you can retrieve a large chunk of data within 5–12 hours
AWS cloud provides a secure virtual platform where users can deploy their applications. Compared to an on-premises environment, AWS security provides a high level of data protection at a lower cost to its users. There are many types of security services, but Identity and Access Management (IAM) is one the most widely used.
Identity and access management (IAM) is about defining and managing the roles and access privileges of individual network users and the circumstances in which users are granted (or denied) those privileges. In simple words, IAM means providing the right user, the right access to the right resources at the right time.
Why is IAM important you ask?
You may have thousands of employees in your organization, each with different roles, such as administrators, developers, operators and application users. All of them will have usernames and passwords unique to them. In addition, each need different levels of access to a variety of physical and digital systems. Therefore, you’ll need a scalable and secure solution to store all these identities. As they may join different teams or even leave your organization, you’ll need to continually update their access as well.
Let’s discuss how is IAM an essential cloud security element for:
Developer, needs to secure their development pipelines and application deployments.
Cloud Administrator, need to know IAM in order to administer and secure your cloud infrastructure.
Security practitioner, need to know IAM, so that you can audit the access granted to identities and cloud resources.
Identity and access management policies define:
- How users are identified and the roles they are then assigned
- The systems, information, and other areas protected by IAM
- The correct levels of protection and access for sensitive data, systems, information, and locations
- Adding, removing, and amending individuals in the IAM system
- Adding, removing, and amending a role’s access rights in the IAM system
Assigning roles to users
Assigning roles simply means giving temporary credentials to a user to allow access that they didn’t had earlier. You can assign an existing IAM role to an AWS user or group. To do so, follows these steps:
First step, from IAM Dashboard click on Roles in the sidebar and then click on create role.
The first page is asking to choose a trusted entity, which basically just means who is going to be assuming this role. For this particular demo, you’ll be creating a role for users in this account to access resources.
Enter your account ID. Also, if you want to add an extra layer of security then click the checkbox that says Require MFA. Click next.
select which policy you want the role to have. For this demo we are giving user full access to EC2. To find it, type in EC2 and then select the check the box next to the policy name. click next.
Tags helps to organize our resources. After adding a helpful tag, go ahead and click next.
This is the review screen, but this is also where you select a name and description for your role. When choosing a name, you’ll want to choose a unique name that is descriptive and make sure you get it right the first time because you can’t edit the name after you create the role.
click create role. And now you have successfully created a role.
Now if you want your user to assume this role then you need to give them permissions to do so by modifying the policies on the EC2-access group that contains the test-user. To do so, create a new policy that allows the users in this group to assume the above created role.
To do this, you will click on Policies
Click on Create policy.
So, if I want the test-user to assume a role, they’ll need permissions to make that API call. To provide that permission, choose the STS service.
and then filter for the AssumeRole API call and click the box and then select which role you want them to be able to assume. do this by specifying the role ARN.
Click on Review policy.
Give the policy a name and a description. Once done, click Create policy.
And the policy is created successfully.
Attach this policy to group. click on Groups, go to EC2-access group, and then click Attach Policy in the Permissions tab.
Click Attach policy.
Search the policy and check the box next to the policy name.
Click Attach policy.
Now you have created a role and your test user is allowed to assume that role.
In order for the test-user to assume that role, he can do this by clicking on username in AWS console and from the drop down click on switch role.
Enter the account ID and the name of the role you wish to assume (for this demo enter testuser-role).
Click on Switch Role.
And now you have the complete access to the EC2 resources that you didn’t had before.
I hope that you find it an illuminating and bracing, read.