Seeking Compliance over

In the day to day activities the ease in operations can be narrowed down to a number of factors and among them is compliance.

When adopting the cloud there are a do's and don'ts that hold the fabric of how communication, implementation and execution between different services not only in the day to day operations and should adhere to the short term needs or even the long term needs or both, this can only be achieved by combining different sets policies to suite the desired need.

AWS provides a number of services that enable and make it possible to achieve this. In this article i will be addressing different types of policies and how they impact boundaries to access resources from user, role and organization level.
A policies is a set of instructions coupled in different formats json or yaml that outlines boundaries to be adhered to that are set on account, user, role or resource level.

AWS defines them as Objects when associated with an identity or resource, defines their permissions, they are evaluated when an Identity and access management(IAM) principle makes a request.
AWS currently supports seven types of policies

• Identity-based policies
  This are the most commonly use policies in AWS, they can be attached both from a managed or an inline.
  Managed come in two forms AWS managed, this are designed and managed by AWS and customer managed, this are designed by the customer and have an outlined approach over the policies than AWS managed.
  Identity-based also incorporate inline policies which have a strict one-to-one relationship between policy and an identity, they size to be effective when the identity is deleted.
  It is best practice to implement managed policies over due to various reasons they are highly reusable and offer versioning and rolling back the link below provides a detailed summary of all the advantages
  https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html

• Resource-based policies
  They are attached to resources and grant permission to the principal that is specified in the policy, in this case the Principal can be in or another account, it is best practice not to use resource-based policies that include a notprincipal policy element with a deny effect for IAM users or roles that have a permissions boundary policy atached. This causes some IAM users or roles that would have access to the resource to lose access.
  ....

• Permission Boundaries
  They are more of a feature that when set to an entitity, the entity can perform only the actions that are allowed by both its identity -based policies and its permission boundaries.
  When implemented to a user it gives a limit to the permission but cannot provide permissions by its own.

• Organization service control policies
  They define the maximum permissions for an IAM user and role within accounts in the organization or organization unit (OU).
  N/B: SCP'S do not grant permissions

• Organization Resource control policies
  They define maximum permissions for resources for accounts that are within the organization or Organization unit.
  They limit permissions that identity-based and resource-based policies can grant to resources in account within your organization.
  They also don't grant permissions

-Access control lists
They are unique as they are do not adopt a JSON policy document structure. They are cross-account and grant permissions to specified principal.
They cannot offer permissions to entities in the same account.

• Session policies They are paased down as parameters for temporary for a role or federated, the set of permission can be resource-based they can programmatically created and passed in asingle JSON inline session policy document using the POLICY parameter. for an extensive read have a look at the link below. https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session

*Conclusion *
In conclusion policies are divided on two grounds identity based and resource based, if the desired effect is to be implemented to users, roles or groups seek the identity-based route.
When seeking the alternative of granting resources like Amazon s3 implement a resource based approach as it pegs direct access to the resource as highlighted in the policy.