I want to automate the creation of development servers within my org's GCP account that are tied to an individual developer.
I intend to script the copying of relevant credentials (think crypto key for GitHub). How do I lockdown the VM so that only a single user can access it. GCP has options like block-project-ssh-keys but we've found that all users are still able to login using gcloud compute ssh.
I fear this may require a really complex IAM configuration.
Is there an easy way to accomplish this? (IAM or otherwise)
Has anyone seen a project that has automated this or something similar to this? (IAM provisioning of a new tag/group/etc. using a script when a new user joins the org)
Enable OS Login on the project, ideally by using an organizational policy constraint. OS Login automatically disables metadata-based SSH keys.
Grant OS Login roles individually per VM and user so that each user can only login to their own VM.
Either don't attach service accounts to the VMs at all, or create dedicated service accounts per VM. Then grant users the Service Account user role on "their" service account only.
Don't grant any Compute* roles beyond Compute Viewer on the project. In particular, don't grant Compute Admin or Compute Instance Admin, or any other role that lets users modify instance metadata (because that would let them alter startup and shutdown scripts).
Optionally:
Grant the users Compute Viewer on the project. That ensures that they can list VMs in the Cloud Console.
Only allow SSH access via IAP TCP forwarding, and grant the IAP-secured tunnel user role on a per-VM, per-user basis.
Related
I got an developer intern. I need him to access GCP paid VM Instance I created so he can start developing. He should have root access through sudo, and preferably his own username linux account so we can see his files when he clones repo's,installs services,etc.
He should not: have access to modify instance, no access to change discs or instance size, no access to any other resource. Just ssh and root inside a vm.
His account is under his personal email abc..#gmail.com
What exact permissions do I need to give him?
a) I used the default service account, but I could switch it to project specific service account that will soon also run cloud functions.
b) For google employees, there should really be a guide/tour for "grant access" that allows people who have less then 10 vm instances follow it to grant access properly without delay or compromising security. He is unable to do paid work :(.
Related:
52756755(why does he need compute admin role for a developer, I need him only to develop and not maintain the instance)
62925708 (why does the user need service account role? He does not need to be creating paid instances)
49384500 (You do not have sufficient permissions to ssh into this instance)
do not have permission to ssh into this instance(
You do not have sufficient permissions to SSH into this instance. You need one of compute.instances.setMetadata, compute.projects.setCommonInstanceMetadata or compute.instances.osLogin (with OsLogin enabled) and iam.serviceAccounts.actAs.
If the person has #gmail.com domain then he is an external user and needs to be given external user permission.
Go to IAM & Admin -> From the Project menu select All and click the top organization:
Add the Compute OS Login External User
Now under the project Add the following:
Add Project - Viewer
Add Compute Engine - Service Account User
[optional]Add Compute Engine -Compute View
**although the Compute View is optional to just ssh, but it does help the developer/programmer/intern to know what they are running and recommend configuration changes when program is ready for golive.
And finally we need to give permission at the instance level. So go to Compute Engine -> VM Instances -> Permissions -> Add Principal -> "Compute OS Admin Login" if you want them to use sudo or if just a regular user "Compute OS Login"
Open the instance, click edit and enable OS-Login under Metadata. Add the following
Key: enable-oslogin
Value: TRUE
Stop and start the instance. You need it for permission to take effect. During troubleshooting none of this worked until we restarted the instance, and magically fixed.
If you need to manage user access to your Linux VM instances, you can use one of the following methods:
OS Login
Managing SSH keys in metadata
Temporarily grant a user access to an instance
To give a user the ability to connect to a VM instance using SSH
without granting them the ability to manage Compute Engine resources,
add the user's public key to the project, or add a user's public key
to a specific instance. Using this method, you can avoid adding a user
as a project member, while still granting them access to specific
instances.
More information about granting users SSH to VM instances can be found here.
Regarding your question about the roles required and why, here is more information about granting access to an organization using Cloud IAM roles.
More information about Access control for users in Cloud compute Engine here.
About roles and permissions
If you need your employee to be able to see the project you need to grant the access to the project according to your needs.
The basic roles are owner, editor and viewer. Here you will find a more detailed explanation about roles and permissions using Cloud IAM to control the access for your project.
And in this page you will find a complete list of the roles and permissions included in Cloud compute engine.
On the other hand in this guide about setup OS login, the roles and permission required to complete the process are included. OS login is an option suitable to resolve your issue.
How may you enable a single IAM user to access a single VM via SSH or cloudshell?
I've tried every variation of Compute Admin permissions, along with a condition on the resource name (matching the VM name) and they are not adequate; i.e. - the users connection is always unexpectedly closed.
Cloud shell is also not available to the user.
The only way the user can access either resources is if they are granted the Owner role.
Here is a similar question, duplicate it if you want but it is unanswered (1 answer does not solve the problem), SSH into a VM instance managed by an Instance Group in GCP without Owner IAM permission on the project
You can try OS login. OS Login simplifies SSH access management by linking your Linux user account to your Google identity. Administrators can easily manage access to instances at either an instance or project level by setting IAM permissions.
OS Login provides the following benefits:
Automatic Linux account lifecycle management
Fine grained authorization using Google IAM - Project and instance-level administrators can use IAM to grant SSH access to a
user's Google identity without granting a broader set of privileges.
For example, you can grant a user permissions to log into the system,
but not the ability to run commands such as sudo. Google checks these
permissions to determine whether a user can log into a VM instance.
Automatic permission updates
Ability to import existing Linux accounts
How to Setting up OS Login
You can apply the metadata values to your projects or VMs by using one
of the following options:
Option 1: Set enable-oslogin in project-wide metadata so that it applies to all the instances in your project.
In the Google Cloud Console, go to the Metadata page.
Click Edit.
Add a metadata entry, setting the key to enable-oslogin and the value to TRUE. Alternatively, set the value to FALSE to disable the
feature.
Click Save to apply the changes.
Option 2: Set enable-oslogin in the instance metadata of an existing instance.
In the Google Cloud Console, go to the VM instances page.
Click the name of the instance that you want to enable OS Login on.
On the instance details page, click Edit.
Under Custom metadata, add a metadata entry, setting the key to enable-oslogin and the value to TRUE. Alternatively, set the value to
FALSE to disable OS Login on the instance.
Option 3: Enable OS Login when you create an instance.
In the Cloud Console, go to the Create an instance page.
Expand Networking, disks, security, management, sole tenancy to reveal additional configuration options.
Expand the Security section.
Expand the Manage access section.
Select Control VM access through IAM permissions.
To create the VM, click Create.
If you want to use 2-step verification, please follow this link:
Setting up OS Login with 2-step verification.
You can try to grant following permissions to use IAP TCP forwarding
roles/iap.tunnelResourceAccessor
roles/compute.instanceAdmin.v1
https://cloud.google.com/iap/docs/using-tcp-forwarding
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.
I created a new VM in a google compute engine project. I changed the "Compute Engine" access scope to "Read Write" after creating the VM.
On the existing (long-running) VM, if I do:
gcloud iam service-accounts list
I see the default service account for the project.
However, if I do the same thing on the newly created VM, I get an error:
gcloud iam service-accounts list
ERROR: (gcloud.iam.service-accounts.list) User [<service-account>] does not have permission to access projects instance [<project>] (or it may not exist): Request had insufficient authentication scopes.
The original VM is a ubuntu-16, the new VM is ubuntu-18 freshly created from a google image.
If I look at the project IAM roles, my user has the following roles:
- Access Approval Config Editor
- Compute Admin
- Role Viewer
- Service Account Admin
- Owner
- Organization Administrator
What am I missing?
The access scopes for the two VMs are the same:
- Compute Engine Read Write
- Service Control Enabled
- Service Management Read Only
- Stackdriver Logging API Write Only
- Stackdriver Monitoring API Write Only
- Stackdriver Trace Write Only
- Storage Read Only
What controls access for the individual VMs other than the access scopes?
The problem was the SSH window was running under the service account, not my normal user account. I needed to run
gcloud init
to reconfigure to use my regular account.
I discovered this by doing
gcloud config list
on both machines.
PART 1
What controls access for the individual VMs other than the access
scopes?
The union of Compute Engine Scopes and service account permissions.
Google Compute Engine scopes limit permissions, scopes do not grant permissions.
The service account assigned to Compute Engine determines the permissions/roles that are available. Scopes can limit those permissions granted to the service account. Scopes cannot grant permissions that the service account does not already have.
Scopes are a legacy authorization mechanism.
PART 2
gcloud iam service-accounts list ERROR:
(gcloud.iam.service-accounts.list) User [] does not
have permission to access projects instance [] (or it may not
exist): Request had insufficient authentication scopes.
Part of this message is confusing to most people. Scopes are a legacy authentication mechanism that Google used before IAM. Scopes are similar to permissions and in this message mean OAuth 2 Permissions.
The command gcloud iam service-accounts list requires the permission iam.serviceAccounts.list which is present in roles such as roles/iam.serviceAccountUser named Service Account User. The service account mentioned in the error does not have one of the roles granting the permission to list service accounts or the Scopes are limiting a permission granted to the service account. Read my recommendation at the end.
Service Account Roles
Part 3
If I look at the project IAM roles, my user has the following roles:
The roles assigned to the user are not related to the roles assigned to the Compute Engine service account.
If you logged into Compute Engine using SSH and did not do anything else to authenticate then you are using Compute Engine Default Service Account credentials. Service Account and Scopes affect your permissions.
If you logged into Compute Engine using SSH and you use your own account for authentication (gcloud auth login or similar) then your user identity is using the the permissions granted to your user account and not the Compute Engine Default service account credentials.
Part 4
The original VM is a ubuntu-16, the new VM is ubuntu-18 freshly
created from a google image.
If the scopes are the same for both VMs, then your issue is the service account. Normally Compute Engine VMs use the Compute Engine Default Service Account. You can change which service account is assigned to each VM. Double check what is assigned to each VM.
Summary
I recommend that you set the scopes to Allow full access to all Cloud APIs and control the permissions via roles granted to the service account. Do not use roles such as Project Owner or Project Editor. Those roles are very powerful. Use fine grained permissions for each Google Cloud service that Compute Engine needs to access.
I have an Amazon Web Services account which will be used to host the backed of an app. The backend uses PHP/MySQL and will most likely use an EC2 instance and RDS. I have my own account which has access to everything. I need to create an account for a developer to put the backend on AWS but I don't want them to have access to anything except what they need. I know how to create IAM users and Groups but I don't know which permissions to grant the developer. Under Select Policy Template there is a Power User template, is that good for a developer? Has anyone done this before?
The Power User Access template in AWS Identity and Access Management (IAM) grants permission to do ANYTHING except using IAM. A user with this permission can view, create or remove any resources in your AWS account, but they could not create new users or modify any user permissions.
It is recommended that you only give people the least amount of privilege required to use AWS, so that they do not intentional nor accidentally do something unwanted. However, if you do not have enough knowledge of AWS to know what functionality is required, you will most likely need to trust the developer to configure the system for your needs.
A few tips:
Only give them access via an IAM User -- never give them your root credentials
If you don't know what permissions are required, then "Power User" is at least safer than "Administrator" since they cannot edit IAM settings
When they have completed their work, revoke their access so they cannot create any more AWS resources
Determine whether you also wish to revoke access to the EC2 instances (you'll have to do this on the instances themselves)
You may need to define some roles that will be used with Amazon EC2 -- these are defined in IAM, so the developer will not have permission to create the roles himself
Ask the developer for documentation of what he has deployed
Turn on Detailed Billing to identify what AWS charges you are receiving and check them against the documentation
Turn on CloudTrail to activate auditing of your account (it is activated per-region)
Alternatively, you could do all the AWS configuration (launching an EC2 instance, creating the database) and only let the developer login to the EC2 instance itself. That way, they would not need access to your AWS account.