Skip to main content
Sign Out

Welcome to Dell

My Account
  • Place orders quickly and easily
  • View orders and track your shipping status
  • Create and access a list of your products
  • Manage your Dell EMC sites, products, and product-level contacts using Company Administration.
Sign In Create an Account Premier Sign In Partner Program Sign In
Contact Us

Dell ObjectScale 1.3 Administration Guide

PDF

IAM Policies and ACLs

A policy is an object that when associated with an identity or resource defines their permissions. Permissions in the policies determine if the request is permitted or denied.

IAM Policies

ObjectScale IAM enables creation, modification, listing, assigning, and deletion of policies on an identity or resource. IAM policies are stored in JSON format.

Using policies you can:

  • Specify actions on a resource.
  • Identify resources.
  • Identify principals that are applicable for the policies.
  • Specify conditions that are applicable

IAM policies define permissions for an action regardless of the method that you use to perform the operation. The following policy types, are designed for use in ObjectScale:

Table 1. Policy Types
Policies Description
Identity-based policies Policies that are assigned to users, groups, and roles which grant permissions to an identity.
  • Inline Policies
  • Managed Policies (Both ObjectScale and Customer managed)
Resource-based policies Resource-based policies are inline policies that are assigned to an ObjectScale resource that grants specified principal permission to perform specific action on the resource.
  • Bucket Policy - Tweaked existing support for bucket policies to support IAM use cases.
  • Trust Policy - Is a resource-based policy that is attached to an IAM role. Trust policies identify the principal entities that can assume the role.
Permission Boundaries Use a managed policy as the permissions boundary for an IAM entity (user or role). That policy defines the maximum permissions that the identity-based policies can grant to an entity, but does not grant permissions. Permissions boundaries do not define the maximum permissions that a resource-based policy can grant to an entity.
Session policies Session policies are used with AssumeRole and AssumeRoleWithSAML APIs. Session policies limit the permissions that the identity-based policies of a role or user grants to the session. Session policies limit permissions for a created session, but do not grant permissions.
Access Control Lists (ACLs) ACLs are cross-account permissions policies that grant permissions to the specified principal. ACLs cannot grant permissions to entities within the same account.
NOTE:If there is an explicit deny in any policy, then the request is denied otherwise there must be a policy that explicitly allows the request. If neither then by default the request is denied.

Policy Basics

Policy is made up of one or list of statements. A statement is contained within a series of elements.

Version
Specify the version of the policy language that you want to use. As a best practice, use the latest 2012-10-17 version.
Statement
Use this main policy element as a container for the following elements. You can include more than one statement in a policy.
Sid
(Optional) Include an optional statement ID to differentiate between your statements.
Effect
Use Allow or Deny to indicate whether the policy allows or denies access.
Principal
(Required in only some circumstances) If you create a resource-based policy, you must indicate the account, user, role, or federated user to which you would like to allow or deny access. If you are creating an IAM permissions policy to attach to a user or role, you cannot include this element. The principal is implied as that user or role.
Action
Include a list of actions that the policy allows or denies.
Resource
ARN of resources the permission applied on. * apply to all resources.
Condition
(Optional) Specify the circumstances under which the policy grants permission.

ACLs

Access control lists allow you to manage access to objects and buckets. An ACL is attached to all objects and buckets. With S3 ObjectScale IAM access:

  • Buckets are owned by the account to which they belong and objects are owned by the account to which the user that created the object belongs.

  • Buckets and object owners can never be changed.

  • Only an account can be a non-group grantee in an ACL.

Rate this content

Accurate
Useful
Easy to understand
Was this article helpful?
0/3000 characters
  Please provide ratings (1-5 stars).
  Please provide ratings (1-5 stars).
  Please provide ratings (1-5 stars).
  Please select whether the article was helpful or not.
  Comments cannot contain these special characters: <>()\