I set up my team members with CloudBank accounts using the CloudBank portal. We all want to access Object Storage on the cloud from computers that are not on the cloud (like our laptops and some other servers). The problem is we want to do this programmatically – in code – using authentication strings. Can we do this as CloudBank Users? Or do we have to be IAM Users? I gather they are not the same thing.
The short answer is that a CloudBank User (abbreviated CB-User) is different from an IAM User for a particular cloud (AWS, Azure, GCP, IBM). There are circumstances where a research team may need to make use of IAM Users. Since this is a non-trivial topic: Please see the full response located
at this link.
(The above link will be relocated to CloudBank Technical Solutions at a later time.)
-
When a research team starts using the cloud via CloudBank, the Principal Investigator (PI) is given Administrator access to a particular cloud account, for example an account on the AWS cloud. This access is via the Identity and Access Management platform CILogon.
-
The PI can create additional CloudBank User accounts for other team members.
This has the pleasant benefit that those team members can log in to the cloud console
via CloudBank, all within a web browser, using their University email identity. -
Let’s consider a team member with a CB-User account for a moment: What can they do, and
are there any limitations placed on them? For the moment we assume everything from here onward
applies to using the AWS cloud.-
The CB-User can log in to the AWS console, let’s suppose as a Power User. They can
start virtual machines, create storage buckets, upload datasets, create serverless functions, and so on: They can use all of the AWS services with the exception of IAM services. So far so good; but let’s take a moment to understand what IAM services on the AWS cloud are. -
Hidden beneath this straightforward console access is the AWS concept of a Role.
This Role is like an access badge, essentially granting the CB-User access privileges
my means of an attached Policy. The main point here is that the Role makes use of
temporary (rather than persistent) credentials. This is a security measure analogous to
changing your password every time you log in to a computer: Old passwords don’t exist.
-
Outline of what follows
- Define IAM services within the cloud, cloud-relative, in contrast to CB-User IAM
- Stay specific to AWS; define AWS-User as an IAM User on AWS, distinct from CB-User
- Specific to AWS: Define Access Keys associated with an AWS-User
- Define the API and the CLI
- Describe using Access Keys to configure API / CLI use
- Warning
- Conclude: If you want programmatic access to AWS you will need an Access Key
- …and this implies an AWS-User identity
- …and this implies learning security measures
What follows are the original notes
On AWS they are doing this by means of a Role with those corresponding permissions attached. The technical name for the permission set is a Policy. However one thing that they cannot do is generate IAM Access Keys. This is because on AWS a Role is distinct from an IAM User. Here we mean an AWS IAM User, not a CILogon IAM User. So we see here a limitation on the CloudBank User. It remains to ask “Under what circumstances is an Access Key necessary?” and “How do we create AWS IAM User accounts so that this feature is available to the team members?”
To answer the first question: The Access Key allows you to use the cloud interface, in fact an Application Programming Interface (API) to conduct transactions with the cloud from an external computer. This includes, for example, uploading data to cloud storage. So if the team member wants to regularly upload data to AWS object storage – suppose this is a thousand data files – they can conveniently do so using a program running on their local computer: Provided the code can authenticate to the AWS cloud using an Access Key.
At this point we have to interrupt our narrative to warn you: Access Keys can allow the holder to do practically anything on the cloud; and the cloud costs money. So Access Keys should be managed with the same care as the passcode to your bank account. In particular: If you use open source version control services like GitHub, you absolutely must invest time in understanding how to keep Access Keys from winding up there where malicious persons can find and use them for their own purposes.
Now that we have established that your team may have a need to use Access Keys, let’s describe how to grant them AWS IAM User status so that Access Keys become available. We return to the project PI who is logged in to the AWS console. They have admin priviliges and so can navigate within the console to the IAM User page. Here they create a new IAM User, ensure that this IAM User has an appropriate Policy associated with that identity, and enable that IAM User to generate Access Keys. Again we emphasize that this new IAM User is an “internal to AWS” IAM User, which is completely independent of the CloudBank IAM User. Hence one person might have two IAM User accounts associated with a single cloud account. If only one of these is actually needed it might be simpler to just use that and forego the other one.
Once the AWS IAM User account is generated the console provides authentication credentials. The PI will share these with the team member; they will login to the console with the new credentials; and they can now generate an Access Key to be downloaded, carefully managed in a secure location away from GitHub repositories, and used to authenticate when using the API. Incidentally this method of authentication is also used by the Command Line Interface (CLI) to the cloud.
This summary includes a lot of jargon; so there is implicitly a learning curve for both the PI and the research team members to negotiate. This is why CloudBank includes an onboarding process to impress on everyone involved the importance of developing skills and best practices to keep your cloud account safe from unwanted access.