I am looking to try to restrict the use of Primitive Roles in a GCP environment using Terraform. However, I am finding most solutions are more on the side of detection rather than prevention.
I tried initially to do this with Organization Policies but am not finding the appropriate Constraint in the documentation.
Related
I'm trying to set up AWS IAM Identity Center (successor to AWS Single Sign-On) for my organisation, and my team has a strong preference for Infrastructure as Code (IaC) wherever practical.
While exploring solutions, I was able to set up an Instance with several Users, Groups and Permission Sets using the Management Console UI. However, now I have come to set up something more long-term, I can't find any way to create an Instance via either CloudFormation or the AWS CLI.
When looking for documentation, I found the CloudFormation reference for AWS SSO, as well as the AWS CLI reference for the sso-admin subcommand. Neither mention any operations that create instances. Neither does the AWS SSO API reference, which leads me to think programmatic access may not be possible.
Is it possible to create an Instance through code rather than the Management Console?
If it is possible, what have I missed?
I am looking into restricting the permissions of some of our more junior team members that are not using most of their given permissions on GCP.
These users are exclusively creating+using the VM instances, as well as using GCS. They currently have the role of Editor. Looking at the existing per-defined roles, it looks to me as though the Compute Instance Admin (v1) and Storage Admin roles would fit their use better.
However, looking at the permission diff, a number of permissions ending in setIamPolicy jumps out to me as potentially dangerous. The diff also contains a number of createTagBinding and deleteTagBinding permissions that seem less alarming. What would be the consequence of granting these?
I'm surprised that I was not able to find a more granular Editor-level role, for Compute Instance and Storage. These seem to me like very common roles other companies might want to use. As far as I can tell, the User,Viewer, Creator or such roles specific to Compute Instance and Storage all seem to lack some core permission we currently need, such as listing buckets, creating VMs, or logging onto VMs with sudo rights. Have I overlooked some existing roles? Is there a way to create an "intersection role", granting only permissions that both parent roles have?
Basic roles like Editor, Owner, and Viewer should be avoided whenever possible.
The roles you suggested like 'Compute Instance Admin' are preferred.
In terms of permissions ending with setIamPolicy, for the Compute Instance Admin role, they apply only to compute resources like Instances, Snapshots, etc.
They are required to grant permissions to resources somebody with the Admin role creates. They do not allow to create/grant new permissions/roles that go outside of compute resources.
Have a look at the following summary. It shows a similar situation: https://cloud.google.com/iam/docs/resource-hierarchy-access-control
I basically want them to have access to create/modify anything that they create, but not really able to modify/delete existing resources.
Or in some other way put them in their own bubble.
I actually got AWS certified associate in architecture, so should have some idea of whatever you say. I forgot most of what I learned for the test.
For now I made them a PowerUser.
Thanks!
Currently, there is no elegant solution for this in a shared AWS account. If you need this level of separation, creating a sub-account is the way to achieve this.
but not really able to modify/delete existing resources.
You can use resource and/or identity tags and then allow or deny actions based on tags. E. g. you can deny any action for tags env=production. See https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html
You can create simple or more complex Tag Policies to enforce consistent resource tagging.
And there is a way to enforce the owner identity in a tag, so you can allocate costs. (just search the inet for it if you want)
Or in some other way put them in their own bubble.
To keep it simple the development is usually done on a separate (organizational) account and the developers shoup deliver a deployment script/procedure to deploy the resources to other stages (cloudformation, terraform,..) .
. i started by granting PowerUser. then SystemAdministrator
This is something... the developers should not need. If so, you could implement an SCP (Service control policies) to limit even the admin users (deny disabling the cloudtrail, access to sensitive kms, modify roles with certain tags,.. .)
I am in process to use prometheus cloudwatch exporter which can be used for monitoring various AWS accounts. I seen lot of documentation about configuring single IAM user (which are not programmetic) for cross account access but unable to find steps for configuring programmetic user to access cloudwatch across various account.
it will be great if someone can provide me pointers for same
You cannot really have a single IAM role being used cross accounts. What you really need is to create an IAM role that can be assumed by a different user account.
Below link would be helpful in defining a role that can be assumed by a different account:
https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html?shortFooter=true#tutorial_cross-account-with-roles-2
To utilise the cloudwatch exporter, you need to allow the exporter to assume the role in a similar way. You can create these roles quite easily using coding too. Comment with further details on what you need, will help out
Usecase :
I have a GCP setup with :
multiple Google Kubernetes Engine clusters
multiple CloudSQL instances
multiple GCS buckets
Basically, I'd like to give permissions to users with finer granularity than project-wide (ie user A can only access bucket B, but can access CloudSQL instances C and D)
Possible solutions :
For GCS, this is easy and documented.
However, I couldn't find anything similar for the other two. The CloudSQL documentation even seems to say it is not possible (All permissions are applied to the project. You cannot apply different permissions based on the instance or other lower-level object.)
Workarounds explored :
I tried creating custom IAM roles. I was hoping that there would be some way to filter on objects the role is applied to, in a fashion similar to what AWS IAM allows with its Resource filter.
That's apparently not possible here.
For GKE, I can give every user the Kubernetes Engine Cluster Viewer role (which basically just allows to list clusters and basic info about them, as well as logging on with gcloud cli tool), and then use the Kubernetes RBAC engine to give very fine-grained permissions. This works fine, but doesn't allow the user to use the Google web interface, which is extremely handy, especially for a beginner on k8s.
Similarly, for CloudSQL, I can give the Cloud SQL Client role, and manage my users directly through the postgres access control system. This works fine, but my users are able to connect to other instances (they still need an account on these instances, of course). Moreover, operations such as restoring a backup cannot be allowed only on specific instances.
So, have I missed something obvious, or have anybody found some way to work around these limitations ?
For GKE, seems that the only option is using RBAC to give users fine grained permissions by RoleBinding within a namespace or ClusterRoleBinding for cluster-wide permissions.
Regarding CloudSQL, currently not supports instance based permissions, but you can track any updates in this link for this feature request.