In the current Google Cloud Deployment Manager documents.. Seems like you can not create any roles or permissions with it or am I just missing a property or resource type?
You must grant your project's Google APIs service account the primitive roles/owner role so it can apply the IAM policies you define in your configurations. And, When you create or update your deployment, Deployment Manager calls the Identity and Access Management (IAM) API to set the appropriate permissions on the resource.
I invite you to take a look at this Stack overflow thread to get more information.
Related
I need to fetch all the projects and associated resources details underneath an org in GCP. What is the best way to do this. Can i create a service account bound to an organization and what type of roles need to be assigned to the Service account to control all type of resources under an organization.
Can i create a service account bound to an organization?
Yes, you can bound a service account to an organization
What type of roles need to be assigned to the service account to control all type of resources under an organization.
If you need to control resources under your organization only,
"owner" role is enough. But if you need to control folder and organization itself too, "owner" + "organization administrator" role is necessary.
The service account can be granted IAM roles that let it access resources. The service account is used as the identity of the application, and the service account's roles control which resources the application can access.
You can grant users permissions using custom roles. These roles operate on the principle of least privilege, and generally provide only the minimum necessary permissions required to do a particular task.Because of their restricted permissions, however, custom roles may cause many resources in your hierarchy to be omitted when executing a list operation. When performing searches as a user that has been granted a custom role, it can be difficult to tell why certain resources are not appearing.
To get the permissions that you need to create and manage custom roles, ask your administrator to grant you the following IAM roles:
To manage roles for a project: Role Administrator (roles/iam.roleAdmin) on the project that you want to manage roles for
To manage roles for an organization: Organization Role Administrator (roles/iam.organizationRoleAdmin) on the organization that you want to manage roles for.
As mentioned there is no single role that can be given to a service account to control all types of resources. If a user needs access to a specific Google Cloud resource, you can grant the user a role for that resource. Some examples of resources are projects, Compute Engine instances, and Cloud Storage buckets.
Some services support granting IAM permissions at a granularity finer than the project level. For example, you can grant the Storage Admin role (roles/storage.admin) to a user for a particular Cloud Storage bucket, or you can grant the Compute Instance Admin role (roles/compute.instanceAdmin) to a user for a specific Compute Engine instance.
To list all the resources in the resource hierarchy, Grant a service account the list and get permissions for Organizations, Folders, and Projects on the Organization resource.
I am looking to Restrict creation of VMs on GCP projects. Any workaround for this request.
You might want to try IAM Roles if you do a proper role segmentation within the users of your organization you can restrict all users/groups from creating VMw on your GCP project. Here is another link regarding IAM
The compute IAM role are too broad. If you want finer control, you need to create a custom role without this permission compute.instances.create
You can assign in IAM just permission to create instance. Here are some documentation what roles you can use.
With IAM, every API method in Compute Engine API requires that the identity making the API request has the appropriate permissions to use the resource. Permissions are granted by setting policies that grant roles to a member (user, group, or service account) of your project.
The following tables describe the predefined Compute Engine IAM roles, as well as the permissions contained within each role. Each role contains a set of permissions that is suitable for a specific task. For example, the Instance Admin roles grant permissions to manage instances, the network-related roles include permissions to manage network-related resources, and the security role includes permissions to manage security-related resources, like firewalls and SSL certificates.
Compute Admin role
Name Description Permissions
roles/compute.admin
Full control of all Compute Engine resources.
If the user will be managing virtual machine instances that are configured to run as a service account, you must also grant the roles/iam.serviceAccountUser role.
compute.*
resourcemanager.projects.get
resourcemanager.projects.list
serviceusage.quotas.get
serviceusage.services.get
serviceusage.services.list
click here for more documentation.
Set Quotas in GCP , Quota for VMs are based on the region.
https://cloud.google.com/compute/quotas#understanding_quotas
"The VM instances quota is a regional quota and limits the number of VM instances that can exist in a given region, regardless of whether the VM is running. This quota is visible in the Google Cloud console on the Quotas page. "
I created a service account mycustomsa#myproject.iam.gserviceaccount.com.
Following the GCP best practices, I would like to use it in order to run a GCE VM named instance-1 (not yet created).
This VM has to be able to write logs and metrics for Stackdriver.
I identified:
roles/monitoring.metricWriter
roles/logging.logWriter
However:
Do you advise any additional role I should use? (i.e. instance admin)
How should I setup the IAM policy binding at project level to restrict the usage of this service account just for GCE and instance-1?
For writing logs and metrics on Stackdriver those roles are appropriate, you need to define what kind of activities the instance will be doing. However as John pointed in his comment, using a conditional role binding 1 might be useful as they can be added to new or existing IAM policies to further control access to Google Cloud resources.
As for the best practices on SA, I would recommend to make the SA as secure as possible with the following:
-Specify who can act as service accounts. Users who are Service Account Users for a service account can indirectly access all the resources the service account has access to. Therefore, be cautious when granting the serviceAccountUser role to a user.
-Grant the service account only the minimum set of permissions required to achieve their goal. Learn about granting roles to all types of members, including service accounts.
-Create service accounts for each service with only the permissions required for that service.
-Use the display name of a service account to keep track of the service accounts. When you create a service account, populate its display name with the purpose of the service account.
-Define a naming convention for your service accounts.
-Implement processes to automate the rotation of user-managed service account keys.
-Take advantage of the IAM service account API to implement key rotation.
-Audit service accounts and keys using either the serviceAccount.keys.list() method or the Logs Viewer page in the console.
-Do not delete service accounts that are in use by running instances on App Engine or Compute Engine unless you want those applications to lose access to the service account.
How to setup multi-account(project) in GCP, it is possible in AWS by using assume-role, anyone knows how to do it in Google Cloud (GCP)?
I tried to explore AWS equivalent in GCP, but not able to find any document.
As documented, AssumeRole in AWS returns a set of temporary security credentials that you can use to access AWS resources that you might not normally have access to.
In AWS you can create one set of long-term credentials in one account. Then you can use temporary security credentials to access all the other accounts by assuming roles in those accounts.
The equivalent of the above in GCP would be creating short-lived credentials for service accounts to impersonate their identities (Documentation link).
Accordingly, in GCP you have the “caller” and the “limited-privilege service account” for whom the credential is created.
To implement this scenario, first, use handy documentation on Service Accounts and Cloud IAM Permission Roles in GCP, as each account is a Service Account with specific role permissions, in order to understand how accounts work in GCP.
The link I posted above, provides detailed information on the flows that allow a caller to create short-lived credentials for a service account and the supported credential types.
Additionally, this link can assist you in visualizing and understanding the resource hierarchy architecture in GCP and give you examples on how to structure your project according to your organization’s structure.
The basic answer is "Service Roles". Limited-time service roles are available.
For assigning permissions across projects (but still in the same organization), you can create a custom role.
For letting any user assume the role of a service account, use the Service Account user role.
For limited-time authorization tokens, you have OAuth 2.0 for server-to-server calls, particularly with JWT where available.
Is there an option to grant read-only access to an Amazon Web Services (AWS) account?
What I'd like to achieve is to be able to see instances and configurations without having to log in as a user who has administrative permissions to avoid accidental changes.
No. An AWS Account cannot be made "read-only".
However, you can create a User in Identity and Access Management (IAM) and assign them "Read Only" permissions, which means they can interact with AWS but cannot change anything. However, this would still require that they login or at least use a set of credentials with calling the API or using the Command-Line Interface (CLI).
If your main goal is to avoid accidental changes, try this:
Create a User in IAM who has minimal permissions (eg read-only, and probably also permissions to create new resources such as buckets and instances)
Create a Role in IAM that has elevated permissions
Setup the User with the ability to "assume" the Role within the web browser
This way, the User won't have 'dangerous' permissions unless they specifically request it. A visual indication then shows when they are using this alternate role (which can also grant access to a different AWS Account).
For details, see:
Blog: Cross-Account Access in the AWS Management Console
Article: Enable a New Feature in the AWS Management Console: Cross-Account Access