Cluster admin roles

[nangu001]

Adding cluster-admin-roles for inf-admin-t2 and inf-admin-t3.

[mcgin314]

Looks like we discussed.

[badra001]

I do not want to do this this way. The SSO auth part will vary, and we do not want the use of the specific permissionset as part of it. We need to stick with the TF formatted profile of {account_id}-{alias}.

I want the entirety of the cluster build to use a role which is assumed, r-inf-terraform-eks. This role does not yet exist in every account, but it will through the use of a stackset.

What we need to setup this role is the list of permissions for creating and administering the cluster and all the sub-components that it uses.

Then, the provider would be something like "aws.eks" which is setup using an assume role profile to the r-inf-terraform-eks.

This way, as the cluster is built, we will always have the builder available as this role, and it will simplify access to the k8s components.

This is similar to the cluster admin roles.

[badra001]

Do not hardcode role ARNs here, especially SSO roles. This is not at all portable.

[badra001]

I do not want to do this this way. The SSO auth part will vary, and we do not want the use of the specific permissionset as part of it. We need to stick with the TF formatted profile of {account_id}-{alias}.

I want the entirety of the cluster build to use a role which is assumed, r-inf-terraform-eks. This role does not yet exist in every account, but it will through the use of a stackset.

What we need to setup this role is the list of permissions for creating and administering the cluster and all the sub-components that it uses.

Then, the provider would be something like "aws.eks" which is setup using an assume role profile to the r-inf-terraform-eks.

This way, as the cluster is built, we will always have the builder available as this role, and it will simplify access to the k8s components.

This is similar to the cluster admin roles.

This is also probably the time to look at the new authentication configuration options. Specifically, I believe we want to use API_AND_CONFIG_MAP.

[badra001]

I do not want to do this this way. The SSO auth part will vary, and we do not want the use of the specific permissionset as part of it. We need to stick with the TF formatted profile of {account_id}-{alias}.
I want the entirety of the cluster build to use a role which is assumed, r-inf-terraform-eks. This role does not yet exist in every account, but it will through the use of a stackset.
What we need to setup this role is the list of permissions for creating and administering the cluster and all the sub-components that it uses.
Then, the provider would be something like "aws.eks" which is setup using an assume role profile to the r-inf-terraform-eks.
This way, as the cluster is built, we will always have the builder available as this role, and it will simplify access to the k8s components.
This is similar to the cluster admin roles.

This is also probably the time to look at the new authentication configuration options. Specifically, I believe we want to use API_AND_CONFIG_MAP.

We do need someone to research the needed permissions to apply to such a role. I had asked someone months ago, but nothing came out of it.

[morga471]

AWS managed policies for Amazon Elastic Kubernetes Service Should we perhaps consider using these for the EKS Permissions boundary you describe?

Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they're available for all AWS customers to use. We recommend that you reduce permissions further by defining [customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) that are specific to your use cases.

My thought is to start with the Managed Policy as the default used for the r-inf-terraform-eks, then a customer admin can be granted the scoped admin role (or the defined admin role). This way we have the boundary permission represented by the r-inf-terraform-* for a given service. Thoughts?

[badra001]

AWS managed policies for Amazon Elastic Kubernetes Service Should we perhaps consider using these for the EKS Permissions boundary you describe?

Keep in mind that AWS managed policies might not grant least-privilege permissions for your specific use cases because they're available for all AWS customers to use. We recommend that you reduce permissions further by defining [customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) that are specific to your use cases.

My thought is to start with the Managed Policy as the default used for the r-inf-terraform-eks, then a customer admin can be granted the scoped admin role (or the defined admin role). This way we have the boundary permission represented by the r-inf-terraform-* for a given service. Thoughts?

These policies are what is needed by the nodes to RUN EKS, not to provision the EKS necessarily.

I do not intend for a customer to get the r-inf-terraform-eks role. They would be using the cluster admin role (also through an assume role).

[morga471]

https://github.e.it.census.gov/terraform/252903981224-ma5-gov/pull/249
I think that was the reason you wanted this eks role added to the r-inf-terraform role stackset?

[morga471]

superseeded by #18