Should we continue maintaining / expanding this repo?

[isen-ng]

Because we only have Enterprise support in our AWS production account, that means most developers will not have access to it without requesting for access.

Right now, there are 3 common roles, ReadOnly, PowerUser, SuperAdmin and the support access policy is only available on PowerUser and SuperAdmin roles. Giving PowerUser access to developers who only want to create support tickets seems excessive power to be given to a user.

To facilitate this kind of use case, should there be a "SupportUser" common role? or allow the support policy to be attached to the "ReadOnly" user with a boolean flag.

(I understand that I can create my own support role in my own terraform, but I think this might be a common enough use-case to be added into this module)

# Built-in support role policy arn
arn:aws:iam::aws:policy/job-function/SupportUser

Thoughts? If feedback is positive, I can send a PR.

[sshvetsov]

Hi @isen-ng, good question.

There are few parts to this:

1. Indeed it's a good idea for each account to have some sort of IAM role that has both a ViewOnlyAcces and SupportUser managed policies attached to it, so account administrators can grant specific users privileges to view resource meta data and open support cases.

2. I'm starting to think that this repo and the approach we took to simplify/speed up our users' ability to create IAM Roles was misguided, as we poorly abstracted IAM security - critical part of infrastructure management away from our end users, and unintentionally added more operational overhead required to update roles created by these modules caused by multi-level module nesting.

To expand on point 2:

• Relying on overly permissive roles like SuperUser and PowerUser is a significant security risk, and having such roles provided by default inevitably leads to very poor security practices, where admins over-rely on them, instead of creating roles with least privilege access.
• Once these roles are provisioned, it is very unlikely that admins will update their code, even if the module is updated.
• Creating nested Terrafrom modules seems like a good idea in terms of code re-use, but in practice creates various issues:
  • It creates a lot more overhead to keep modules that reference other modules updated
  • It's much more difficult to keep up with breaking changes introduced by referenced sub-modules. Case in point: common role modules here will reference one of iam-role modules, which reference the underlying "interface" sub-module, I recently tried to update on of my instances of BillingUser module and wrangling terraform state of said module was not a straightforward task and would definitely by outside of beginner's capabilities.

I'm starting to think we should deprecate this repo and the modules in them and instead start creating modules that generate common managed policies, which in turn can be attached to roles created by the more general terraform-aws-iam-role modules. This should simplify module maintenance, reduce number of nested modules and reduce effort required by the end users to update their policies as we iterate over them. To illustrate I would suggest the following changes:

• start creating standalone modules that create policy documents for commonly needed, minimal policies. These could be parametrized with values for resources, principals and conditions to make them more secure be default. They can be used as access policies or boundary policies.
• replace reference to datadog-integration role with reference to external role and one or more managed policies containing minimal required permissions.
• replace billing-user with a standalone managed policy module that can be attached to user role.
• replace product-domain-build-manager with a standalone managed policy module that can be attached to user role.
• delete power-user, super-admin, read-only, rds-enhanced-monitoring modules entirely.
• replace this repo with repository containing curated examples that show how to combine more general roles with managed policy modules and/or custom minimal policies to create secure roles which gran least privileged access.

These are my thoughts on the matter and I'm open to further discussion.

[sshvetsov]

I have renamed this issue, as I think this is a very timely discussion to have and decision to make.

[isen-ng]

I think the purpose of this repository is to simplify the setup of AWS infrastructure for a new team. Personally, having a repository of curated roles vs having a repository of curated policies are the same thing. The role/policies are curated and is unmoving without a PR. So, ultimately, whether it is this repo or a repo or policies, this is a convenience for users to create common roles/policies.

IMO, The main difference is having a repo of curated policies instead of roles (as @sshvetsov has stated) above, is the way the modules are used. A repo of policies is easier to use. If implemented the way @sshvetsov had suggested, it will also decrease the effort required from the maintainer to maintain the repository. Having curated, accurate and detailed examples is important here to hand hold folks new to AWS and IAM-roles to reduce support issues.

Edit: I think many people do not understand the amount of power given to a PowerUser or a SuperAdmin because right now, it's a blanket statement: "Create a PowerUser role with PowerUser policy". If the permissions/policies can be parameterized with defaults, then it will users give a sense of what permissions are REALLY given to a role.

[sshvetsov]

I am also leaning towards creating a repo per policy, rather than one repo full of policies, due to individual versioning (especially with semantic versioning). However, there's a value in having a single place to find/store all curated policies as well. Still not sure what the best way to have both...

[isen-ng]

@sshvetsov Aren't you looking at implementing a private terraform module registry?

[sshvetsov]

Eventually, meanwhile there's a frequent need to group a bunch of small repos in one place, and not only for terraform modules.

-- Sergei (Sent from a phone)

On Tue, Jul 9, 2019, 11:17 Isen notifications@github.com wrote:

@sshvetsov https://github.com/sshvetsov Aren't you looking at implementing a private terraform module registry?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/traveloka/terraform-aws-common-iam-roles/issues/17?email_source=notifications&email_token=AATCUODIKNIMWCJNLZ3YEULP6QGMJA5CNFSM4H6YL4G2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZPA3ZA#issuecomment-509480420, or mute the thread https://github.com/notifications/unsubscribe-auth/AATCUOAQDTZRXCLCFZGLH2LP6QGMJANCNFSM4H6YL4GQ .

[isen-ng]

I think it should be possible to group related modules into 1 git repo. Each module will reside in a subfolder each and have its own release cycle. Its release cycle can mean that it has its own tag and its own CI to release to a module registry.

eg.

 root
--+--
   + module-A - v1.0.1
   + module-B - v2.0.1

tags

ModuleA-v1.0.1
ModuleB-v2.0.1

Before we have terraform registry, each module can still be referred to as:

• git@github.com:shared-repo.git//module-A?ref=ModuleA-v1.0.1
• git@github.com:shared-repo.git//module-B?ref=ModuleB-v2.0.1

Doing something like this should make no sense:

• git@github.com:shared-repo.git//module-A?ref=ModuleB-v2.0.1

However, this means that we are not going to use tag in the way tags are meant to be used, although there is nothing stopping us from using it in this way.

[isen-ng]

or... Git Submodules?

[rafikurnia]

or... Git Submodules?

Hi @isen-ng, a question. From the doc it seems to utilize Git Submodules we still need to use multiple repositories aren't we?

[isen-ng]

Hi @isen-ng, a question. From the doc it seems to utilize Git Submodules we still need to use multiple repositories aren't we?

Yes, it still require multiple git repos but there is 1 git repo with all the modules present. In that sense, developers only need to clone that repo and make changes in it and there is a place to see all the sub-repos.

anyway, git modules is a cumbersome and complex command to use...

[sshvetsov]

Perhaps I mis-remember how git-modules works, but wouldn't changes to sub-repos still need to be made/committed into the underlying repos themselves? I believe parent repo can be cloned and used as a whole, but changes need to be made to each individual repo directly. This would provide a logical grouping of sorts, but it's hardly different from simply having a repo with links to other repos and examples of their use. Thoughts?

[isen-ng]

it's hardly different from simply having a repo with links to other repos and examples of their use

now that you mentioned this.... I agree. git submodules provide conveniences of being able to clone all the sub modules at once but now you have to commit in the sub repo AND commit in the group repo too.

:/