alphagov/paas-cf

Required IAM Instance profiles are not listed in the pre-requisites section.

jimconner opened this issue · 2 comments

jimconner commented

The README.md states that IAM instance profiles are configured through the account-wide-terraform repository and that it is not publically accessible due to the state file being stored within that repository. No further details of the required instance profiles are provided.

The following IAM instance profiles are required as pre-requisites before deployment can complete successfully.

  • bootstrap-concourse
  • deployer-concourse
  • bosh-director
  • bosh-managed
  • cf-cloudcontroller
  • rds-broker

It would be really great if a sanitised version of the account-wide-terraform repository could be provided, but failing that, details of the required IAM roles and policies for each instance profile should be documented fully.

keymon commented

I completely agree.

90% of the time to deploy paas-cf outside of GDS is spent in creating the right IAM roles and policies, for which there is no information in the public. Even for somebody with knowledge about this project it takes ages to do it.

I think a public version of aws-account-wide-terraform would definitely help and improve the situation, allowing 3rd parties to be able to easily deploy this project.

It should be not difficult to create such repository based on the existing one. AFAIK the main reason why the account-wide-terraform is not public is the fact that the terraform state is commited into the repository. But it is actually a bad practice to do so and it causes problems. I suggest that instead you use a tool like terragrunt: https://github.com/gruntwork-io/terragrunt

In order to remove the existing states, you can use something like:

git filter-branch --force --index-filter 'git rm --cached --ignore-unmatch -r *.tfstate*' --prune-empty --tag-name-filter cat -- --all

Then, I think the aws-account-wide-terraform should:

  • Be splited between basic account permissions configuration and paas-cf specific ones. If I recall correctly, GDS created groups there. But other companies use roles to access to the resources.
  • Grant the permission using a role: e.g. cloudfoundry-admin role, instead of groups. The operators would assume that role using sts. This approach is more flexible than using groups.
samcrang commented

I think this is a nice to have that we can look at again later. Closing.