Community

Blog Events Webinars Tutorials Forum
  1. Blog
  2. Events
  3. Webinars
  4. Tutorials
  5. Forum
Create Account
×
Community Blog Friday Blog - Week 18 - Security with Resource Access Management (RAM)

Friday Blog - Week 18 - Security with Resource Access Management (RAM)

This week, we look at securing our RAM users with custom policy. Let's dive in!

By Jeremy Pedersen

Welcome back for the 18th installment in our weekly blog series! This week we're taking a deep dive into RAM (Resource Access Management). This is a critically important topic for anybody who wants to architect securely on Alibaba Cloud. Let's jump in!

First, some background

Before we jump into the RAM stuff, let's talk about what computer security is and why it's so hard. Then we'll see how RAM can be applied to address security issues around access control.

Let's admit it: computer security is hard

Really hard. While engineers in the physical world have made enormous strides in building safer, more reliable systems, computer security seems to be standing still. Or perhaps even getting worse! Year after year, more and bigger data breaches make the news.

In 2013, Target was hacked and lost information on 110 million customers. That seems like a lot until you compare it to the theft - the same year - of information about 3 billion Yahoo accounts.

Things have not improved since then. Attacks in which hundreds of millions of accounts are compromised are now commonplace.

The pressure many companies are putting on their IT teams to quickly migrate to the cloud can make things worse. A rushed, under-prepared team can easily find themselves in trouble. The big, exciting new world of cloud means there's room for big, exciting mistakes!

Of course, it doesn't have to be like this. A well prepared, cloud-competent team can build applications on the cloud that are more secure than many traditional applications ever were. But why?

Unless you work at a company that specializes in computer security, it's a safe bet that the security teams at companies like Alibaba Cloud, AWS, Azure, or Google Cloud are going to be bigger, better funded, better equipped, and more experienced than your own team. In many cases these teams have more than a decade of experience securing some of the largest distributed computer systems in the world. These people are world-class experts in hardware, software, and platform security.

This doesn't mean you can forget about security entirely: it just means you are free to spend more time worrying about the security of your applications and less time worrying about the security of your underlying infrastructure.

Security fundamentals

In computer security, the attacker almost always has the advantage.

If you give it a little thought, it becomes obvious why this is:

  1. The defender must think about every possible avenue of attack and defend against all of them, all the time.
  2. The attacker only needs to find one weakness and exploit it one time.

This is true both for internal attackers (people within your organization) and outsiders.

Worse, if a truly skilled attacker is targeting you or your organization, specifically, then there's little you can do to stop them. Given enough time, they will probably succeed.

Luckily, most attackers are like pickpockets or robbers in the physical world: they are looking for easy targets. This is why burglar alarms work: the point of a burglar alarm isn't to make your house 100% secure. The point is to get the burglar to choose a different house. In this respect, computer security has a lot in common with security in the physical world.

Going on the defensive

Practicing good computer security isn't just about buying the right tools or using the right software. It's about developing a strong security mindset. This means thinking about security at multiple levels:

  1. Physical security
  2. Platform security
  3. Software (Application) security
  4. Access control
  5. Authentication
  6. Logging and auditing
  7. Monitoring and detection

And lots more! There is no "10 step" checklist you can follow to guarantee good security. There will be many tradeoffs: the list above is just a start.

The advantage of the cloud is that #1 and #2 are handled by your cloud provider. Some cloud providers, like Alibaba Cloud, also give you tools to help with #3 through #7.

What is RAM?

Resource Access Management (RAM) does exactly what it says...it manages access to resources under your Alibaba Cloud account.

RAM is a tool for creating users and roles within your Alibaba Cloud account and assigning permissions to them. This gives you fine-grained control over who has access to what. Referencing the above list, RAM helps you with points #4 and #5. It costs nothing to use RAM, and it's the correct way to assign different levels of permissions to different people and applications. As an Alibaba Cloud user, you should definitely be taking advantage of RAM!

Using RAM the right way

Although it's tempting to ignore RAM and log into your alibabacloud.com account directly using your email address and password, it's a much better security practice to create and use RAM users instead. This lets you give each person in your organization permissions appropriate to their role, and makes auditing easier, since services like ActionTrail will keep a record of which RAM identity was used when a given action was performed, making it easy to determine who did what.

RAM Basics

There are four key concepts you must understand in order to use RAM:

  1. Policies
  2. Users
  3. Roles
  4. Groups

1. RAM Policy

RAM policy sets the rules for what a RAM identity can or cannot do. Each RAM user, group, or role can have multiple policies attached. The policy takes the form of a JSON document, and there are two types:

  1. System Policy
  2. Custom Policy

System Policies are provided for you by Alibaba Cloud. These pre-written policies cover basic use cases. For instance, AdministratorAccess gives full access to everything within an Alibaba Cloud account, while AliyunOSSReadOnlyAccess gives read-only access to OSS (meaning this policy does not allow you to create new OSS buckets or upload or delete files, but does let you see buckets and their contents).

You can attach RAM policies to RAM users, groups, or roles. A single policy can be attached to multiple groups, roles, or users, and each group, role, or user can have multiple policies attached to it. This creates a lot of flexibility in how permissions are assigned.

So what happens if you attach contradictory policies to a user, group, or role? For instance:

  1. You attach Policy A to User A, which allows creation OSS buckets
  2. You attach Policy B to User A, which denies creation of OSS buckets

What will happen? The most restrictive policy wins. Alibaba Cloud's RAM policy follows a "deny first" logic, meaning:

  1. If an action is not explicitly permitted by a user's RAM policy, then it is denied by default.
  2. If one policy allows an action and another denies it, then the action is denied.

This ensures that overlapping policies grant the minimum level of permissions, which can help avoid unforeseen security holes.

2. RAM Users

A RAM user is a type of RAM identity. It is a set of access credentials that allow a user to log into an Alibaba Cloud account. "Log in" here means "authenticate". Authentication can be done in three ways:

  1. Username and password (plus optional MFA)
  2. Access Key (paired with an "Access Key Secret" also known as a "Secret Key")
  3. Temporary token (called an "STS token")

Essentially, RAM users allow you to grant separate access rights to multiple people or applications, allowing them to access a single Alibaba Cloud account using separate credentials and with different permissions. This is a key point I did not stress earlier in the article: RAM users and roles can be used by shellscripts, applications, or even Alibaba Cloud services. There's no rule that says they have to map onto real, physical people.

3. RAM Roles

A RAM role is a special type of virtual identity. Unlike a RAM user, a RAM role is not a logon identity: RAM roles cannot log into the Alibaba Cloud web console or create and use Access Keys.

A RAM role must be assumed (used) by a RAM user. This is a little bit like putting on a uniform in real life.

When a police officer is off duty, he or she does not have any special rights or privileges. However, when he or she goes on duty and puts on their police uniform, they are now assuming the identity of a police officer and can arrest people, write traffic tickets, and so on.

RAM users and RAM roles have a similar relationship. The police officer is the RAM user, and the police uniform is the RAM role. Just like a police uniform, a RAM role can be temporarily "put on" (assumed) by a RAM user, in order to gain additional permissions to perform some action. This is done using the AssumeRole function built into Alibaba Cloud's STS service.

Note: It is also possible for an Alibaba Cloud service to assume a RAM role. This allows a service like E-MapReduce (EMR) to gain temporary access to a user's Alibaba Cloud account when it needs to do things like manage the worker nodes in a user's EMR cluster.

You can also create roles that allow RAM users under other people's Alibaba Cloud accounts to access your account. This the standard way in which cross-account access is managed on Alibaba Cloud, and is an important technique to master if you are operating in a multi-account environment.

4. Groups

Groups are just a convenient way to attach a RAM policy to multiple RAM users at once. When you add a RAM user to a group, the RAM user inherits all the policies associated with that group, in addition to any policies attached directly to the RAM user.

Imagine you have 20 RAM users: 5 administrators, 10 developers, and 10 operations people.

  1. The administrators should have full administrator access to the account.
  2. The developers should have permissions to reboot ECS instances and take disk snapshots.
  3. The ops people should have permissions to create, destroy, and restart ECS instances, as well as take disk snapshots and create, delete, attach, and detach disks.

These 3 groups of people are going to need different RAM policy attachments! Rather than attaching policies one-by-one to each of your 20 users, simply create "developer", "operations", and "admin" groups, move your users into the appropriate group, and then attach your RAM policies to the groups directly.

This has the added benefit that if someone switches roles, you can simply move them from one group (say "admins") into another (say, "developers"), and their associated permissions will be updated automatically.

Getting Fancy: Custom Policies

Users, Roles, and Groups are relatively easy to understand and use, so I won't go into a lot of detail in this article.

The most difficult part of RAM is understanding how to write Custom Policies, so I want to focus on that.

Let's start by creating a new RAM user under our account. Let's call her Ellie: Take a look at the screenshots below to see how we can go about creating this new RAM account (note: you must be logged into your Alibaba Cloud account either as the owner or as a RAM user with the correct permissions to create new RAM users):

01_create_ellie

We then set a password for Ellie and grant her console access (so she can log into the web console). We will not grant her programmatic access, which means she will not have an Access Key (and therefore cannot use the aliyun CLI tool):

02_create_ellie

03_create_ellie

Once the user has been successfully created, we see a page like this one:

04_create_ellie

Great! Now, if we look at the Policies attached to Ellie, we'll see that there aren't any! So what happens if we log in as Ellie? Not much. We can log in just fine, but since we have no permissions (even to list the resources under our account), there isn't much to see. Here are the group and policy attachments for Ellie:

05_groups

06_policies

And here's what we see in the OSS console while logged in as Ellie:

07_ellie_view

Let's contrast this with what the account owner (sometimes called the "root" user) sees:

08_root_view

The account owner has administrator permissions, and can therefore see all OSS buckets under the account.

Attaching a System Policy

Just as a quick test, let's attach an existing System Policy to Ellie's RAM user and see what happens (we need to do this while logged in as the account owner or a RAM account with elevated permissions, of course):

09_add_permissions

10_add_success

Let's actually open up that policy and take a look at the Policy Document that defines the permissions granted by the policy. What does it look like? We should see something like this:

11_open_policies

12_search_policy

13_view_policy_doc

I've copy-pasted the policy here for easy reference:

{
    "Statement": [
        {
            "Action": [
                "oss:Get*",
                "oss:List*"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ],
    "Version": "1"
}

This policy allows Ellie to carry out most of the List or Describe operations in OSS. What is not allowed is creating new buckets or creating/updating objects.

Switching back to Ellie's account, what do we see now?

14_ellie_new_view

Looks like we can now list out all the OSS buckets! Can we add things? Our policy document says we should not be able to do this. Let's try creating a new bucket and see what happens:

15_new_bucket

Sure enough, it fails:

16_access_denied

Our first custom policy

Let's try modifying the policy to allow us access only to a specific OSS bucket. What would that look like? Of course, we have documentation that explains how to create custom RAM policies, and you should check it out, but we're in a hurry! So let's summarize.

First, we can't write a RAM policy until we understand RAM policy structure and syntax. Specifically, what we call policy elements. There are four of them:

  1. Effect: When a user does something that matches this policy, is that action allowed or denied?
  2. Action: The action(s) that this policy applies to (rebooting ECS instances? creating/deleting them?)
  3. Resource: The resource(s) that this policy applies to (all ECS instances? just instances in Hangzhou? just disks?)
  4. Condition: The condition(s) under which the policy takes effect (for instance, maybe a policy only applies when a user has logged in from a specific IP address range or when an ECS instance has a specific tag applied).

Let's start by looking at the AliyunOSSReadOnlyAccess policy again:

{
    "Statement": [
        {
            "Action": [
                "oss:Get*",
                "oss:List*"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ],
    "Version": "1"
}

First, you'll see there is no Condition element: this part of the policy is optional. If you do not include it, then the policy is always applied to the user or role it is attached to.

You'll also notice that the Action, Effect and Resource fields are enclosed inside a Statement. A policy can have multiple Statements, which makes it possible to create more complex policies which allow different levels of access across different resource types.

Looking at the Action field, we see:

"Action": [
    "oss:Get*",
    "oss:List*"
]

The * is a wildcard, meaning we are allowing this user to make any OSS API call that starts with Get or List. This is what gives the user "read-only access" to OSS. Because the Action field needs to specify what actions are allowed at the API level, we are effectively saying "this user can make any API call that starts with Get or List". It's important to have a strong understanding of the API for a particular Alibaba Cloud service, if you want to write custom RAM policies for that service. You can usually find the API reference for a given service in the public documentation. For instance, here are the API docs for OSS.

The Effect is set to Allow, and the Resource is simply set to *, meaning this policy applies to all OSS buckets under the account, regardless of region.

Ok, so let's write ourselves a custom policy that allows full access to OSS, but only for a particular bucket called jdp-beijing-b:

{
    "Version": "1",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "oss:*",
            "Resource": [
                "acs:oss:*:*:jdp-beijing-b",
                "acs:oss:*:*:jdp-beijing-b/*"
            ]
        }
    ]
}

The Resource section here specifies that we are granting access to a particular bucket called jdp-beijing-b and any resources (Objects) it contains:

"Resource": [
    "acs:oss:*:*:jdp-beijing-b",
    "acs:oss:*:*:jdp-beijing-b/*"
]

Some of the fields here are replaced with *, meaning this policy could technically apply to a bucket called jdp-beijing-b in any region, not just Beijing. We'd have to customize the Resource section further to restrict ourselves to Beijing.

Let's create a new custom policy using this JSON code, then attach it to Ellie's RAM account, without deleting her existing AliyunOSSReadOnlyAccess policy. These policies will now take effect together, meaning:

  1. We can see all OSS buckets under the account and list their contents.
  2. We can upload, update, and delete objects inside the bucket jdp-beijing-b

Let's create this new policy, which we'll call "jdp-beijing-b-access":

17_create_custom_policy

18_replace_default

19_click_ok

Next we need to attach this policy to Ellie:

20_locate_ellie

21_add_permissions

22_add_policy

23_success

Now, let's try uploading a file to jdp-beijing-b while logged in as Ellie:

24_choose_bucket

25_choose_upload

26_select_file

27_open_file

28_upload

29_success

It worked! What about jdp-beijing-a, can we upload files to that bucket? Let's try. The upload steps are the same, so here I just show the result:

30_fail

It failed, as expected. Note that we can still see both buckets because of the permissions granted by the AliyunOSSReadOnlyAccess policy, but uploads are limited to jdp-beijing-b, where we have that permission.

Getting Fancier: Roles and Cross-Account Access

We can also get even fancier, and create Roles that allow cross-account access. Using RAM roles, we can:

  1. Create a RAM user under Account A.
  2. Create a RAM role under Account B.
  3. Add a policy to the Account B RAM role, that allows a RAM user in Account A to assume the role.
  4. Log into Account A as the RAM user.
  5. Assume the role.
  6. Do stuff in Account B.

This is how cross-account access is handled on Alibaba Cloud, and it's fully explained in the documentation so we won't go into a lot of details here.

Wrapping up

That's it! You now understand how to create RAM users, write custom policies (at least for OSS), and attach custom policies to RAM users.

This is the first step on the road to developing a better security mindset. You now have the tools to grant only the permissions actually needed to each of your users! Now get out there and start securing stuff! ^_^

I've Got A Question!

Great! Reach out to me at jierui.pjr@alibabacloud.com and I'll do my best to answer in a future Friday Q&A blog.

You can also follow the Alibaba Cloud Academy LinkedIn Page. We'll re-post these blogs there each Friday.

Not a LinkedIn person? We're also on Twitter and YouTube.

OSS RAM Security Alibaba Cloud Resource Access Management Training and Certification custom policy
1 0 0
Share on

Read previous post:

Friday Q&A - Week 17 - Questions From The Vault

Read next post:

Friday Blog - Week 19 - Choosing The Right ECS Instance Type

JDP

71 posts | 152 followers

You may also like

Comments

Dikky Ryan Pratama May 8, 2023 at 4:04 pm

I wanted to take a moment to express my gratitude for the wonderful article you recently published on Alibaba Cloud Blog. Your writing was engaging and insightful, and I found myself fully immersed in the content from start to finish.The way you presented the information was both informative and easy to understand, which made it an enjoyable read for me. Your hard work and dedication to providing high-quality content are truly appreciated.Thank you once again for sharing your knowledge and expertise on this subject. I look forward to reading more of your work in the future.

JDP

71 posts | 152 followers

Related Products

  • RAM(Resource Access Management)

    Secure your cloud resources with Resource Access Management to define fine-grained access permissions for users and groups

    Learn More

  • Resource Management

    Organize and manage your resources in a hierarchical manner by using resource directories, folders, accounts, and resource groups.

    Learn More

  • Security Solution

    Alibaba Cloud is committed to safeguarding the cloud security for every business.

    Learn More

  • ActionTrail

    A service that monitors and records the actions of your Alibaba Cloud account, including the access to and use of Alibaba Cloud services using the Alibaba Cloud Management console, calling API operations, or SDKs.

    Learn More

More Posts by JDP

See All