IAM review

[justinsb]

We should further review the IAM profile to see if we can lock it down further:

• can we prevent even listing other clusters in the same bucket without breaking discovery?
• EC2 permissions
• Volume restrictions

[Amit-PivotalLabs]

I've got a few questions about the master IAM policy being generated today:

1. There's a bunch of ecr actions, are those even necessary? Aren't most images pulled down from https://gcr.io, especially for consistency with using kops against GCE? If this is meant to allow users on AWS to leverage Amazon's ECR, perhaps it can be made optional.
2. Why ec2:*? What EC2 actions does it really even need? I imagine actually creating the cluster (directly or with terraform) will handle all VM and volume creation and volume mounting, why does the master node need to do any EC2 anything?
3. Can the Route53 permissions be locked down to the provided Hosted Zone? Even better, I suspect kops knows up front exactly what record sets it's going to manage, could it lock the resources down from * to just the record sets it's going to create? Not sure if IAM let's you define policies that way.
4. Locking down elasticloadbalancing:* to elasticloadbalancing:DescribeLoadBalancers would be nice in the case that you don't want to allow people to create LoadBalancer services. I'd like to create a Kubernetes cluster and allow folks to use it without them creating new things in my AWS account that are going to cost me money. I can stand up my own ELB and associate it with the ASG for nodes. This together with the ability to specify the --service-node-port-range on the Kube API Server means I can get a bit closer to a nice experience where people can run publicly routable apps on the cluster without anyone having to do much manual work.
5. Why s3:*? Does kops ever write back to the state store bucket? Read-only types of actions should be sufficient, no?

[chrislovecnm]

@justinsb assigning to you.

[chrislovecnm]

I am closing this because this is open: #1873