Managed Object Storage users and access control
S3 tools and applications sign in to a Managed Object Storage service with the access keys of one of its users. What each user can do is decided by the policies attached to it and to its groups. You manage users, policies and groups on the service's Users, Policies and Groups tabs in the Control Panel, or with the UpCloud API. For step-by-step instructions, see How to restrict user access in Managed Object Storage.
Users and access keys
Each service has its own users, separate from the users of your UpCloud account. A user has no password. It signs in with an access key, which is a pair of an access key ID and a secret key.
The secret key is shown only once, when the access key is created. If it's lost, create a new access key and delete the old one.
An access key can be turned off and on again. Requests made with a key that's turned off fail with InvalidAccessKeyId, the same error as for a key that doesn't exist. Deleting a user also deletes its access keys and detaches its policies.
Built-in policies
Every service has five built-in policies. They can't be changed or deleted.
| Policy | Allows |
|---|---|
ECSS3FullAccess | Every S3 action on every bucket, including creating and deleting buckets and changing their settings |
ECSS3ReadOnlyAccess | Listing buckets and files, downloading files and reading bucket settings |
ECSDenyAll | Nothing. It denies every request, whatever the user's other policies allow |
IAMFullAccess | Managing the service's users, access keys, policies, groups and roles through the IAM endpoint |
IAMReadOnlyAccess | Viewing the service's users, policies, groups and roles through the IAM endpoint |
Custom policies
Custom policies are JSON documents in the AWS IAM policy format. Each statement has an Effect (Allow or Deny), the Action it covers, such as s3:GetObject, and the Resource it applies to:
- A bucket is
arn:aws:s3:::<bucket-name>. Actions on the bucket itself, such ass3:ListBucket, use this form. - Files are
arn:aws:s3:::<bucket-name>/*, or a narrower pattern such asarn:aws:s3:::<bucket-name>/reports/*. Actions on files, such ass3:GetObjectands3:PutObject, use this form. *in a name matches any characters, soarn:aws:s3:::staging-*covers every bucket whose name starts withstaging-, including buckets created later.
Statements can have a Condition, for example s3:prefix to limit listing to one folder, or aws:SourceIp to allow requests only from some IP addresses. In aws:SourceIp, write a single address without a suffix, such as 203.0.113.10. A single address written with /32 doesn't match.
A policy can name buckets that don't exist yet. An action that doesn't exist is refused when you create the policy. A policy document can be up to 6,144 characters long. Policy names can contain letters, numbers and the characters +=,.@_-, and they must be unique within the service.
Versions
Changing a custom policy creates a new version of it. The default version is the one that applies. A policy can have up to five versions, and any version except the default can be deleted.
A new default version doesn't reach every request straight away. For a while, some requests still get the previous version's access. Attaching and detaching policies applies to the user's next request, so to take access away at once, detach the policy.
A policy that's attached to a user or group can't be deleted. Detach it first.
How policies combine
A user without any policies can't do anything: every request it makes is refused with AccessDenied. A user's access is everything that its own policies and its groups' policies allow, so adding a narrower policy doesn't take anything away. A Deny always wins over an Allow, wherever it comes from.
Attaching or detaching a policy, and adding a user to a group or removing it, applies to the user's next request.
Groups
A group's policies apply to every user in it. Deleting a group, or removing a user from it, takes away the access the group gave. To see who is in a group, expand its row on the Groups tab.
Bucket policies
A bucket can also have a bucket policy, which applies to every request to that bucket, including requests without access keys. You can edit it with Bucket policy on the bucket's row on the Buckets tab, or with S3 tools. For an example, see How to set up a public read bucket. As in user policies, write single addresses in aws:SourceIp without /32.
Roles and temporary credentials
Roles give temporary access keys to the users that a role's trust policy allows. Those users get the keys from the service's STS endpoint with AssumeRole. You manage roles on the Roles tab or with the API.
IAM and STS endpoints
Besides the S3 endpoint, each service has an IAM endpoint and an STS endpoint, both on port 4443, for example https://abcd1.upcloudobjects.com:4443/iam and https://abcd1.upcloudobjects.com:4443/sts. They're listed on the service's Overview tab, under Public access. Tools that use the AWS IAM and STS APIs can work with them. The AWS CLI, for example, needs --endpoint-url with the endpoint's address.
Calls to the IAM endpoint need a user with IAMFullAccess or IAMReadOnlyAccess. A user with only S3 policies gets AccessDeniedException.
The file manager's user
The Control Panel's file manager uses a user and a role of its own, _upcloud-managed-filebrowser-user and _upcloud-managed-filebrowser-role. The Control Panel adds them to the service the first time you open a bucket in the file manager, and again if they've been deleted. The role can list every bucket and read, upload and delete files in them, so the policies of your own users don't limit what you can do in the file manager. A bucket policy that denies all requests does block the file manager too.