Exploring the Google Cloud OS Login feature and Service Accounts

Introduction

As a Cloud Security Architect at Google Cloud, I get the opportunity to teach classes about security concepts. I recently had to teach a lesson about the OS Login capability on Google Cloud Compute Engine and another lesson on Google Cloud service accounts. I thought it would be helpful to share some of that with others. I also developed some GitHub labs around these topics. I’ll share the link for the labs later in this article.

OS Login

OS Login provides a way to manage SSH access to Compute Engine instances without having to manage individual SSH keys through Compute Engine or project metadata. You use Google Cloud Identity & Access Management (“IAM”) to grant either administrative access (the ability to sudo without supplying a password) or regular access. You can also support POSIX group mapping to provide a consistent group membership experience in your enterprise.

There are two ways to enable the OS Login feature. The first option is to the metadata key enable-oslogin to TRUE at either the project or folder level. The second way is to to enable the organization constraint Require OS Login. After you enable OS Login, you use IAM to grant one of two roles: (1) Compute OS Admin Login for administrative (sudo) access or Compute OS Login for standard access.

After enabling OS Login and granting access using IAM, a Google Cloud user can use the gcloud compute ssh command to connect to the instance. If the instance has OS Login enabled, the instance will interrogate IAM to determine what kind of access the user should have. OS Login will manage the SSH keys for the user and enable the SSH connection. You can also combine OS Login with the Identity-Aware Proxy TCP Forwarding feature to enable you to tunnel to the internal IP addresses of instances to provide additional security. In short, OS Login gives you an easy way to use IAM to manage the end-to-end SSH connection.

Service Accounts

Service accounts are non-user identities that enable applications or workloads to have access to Google Cloud services. A common example of this is to attach a service account to a Compute Engine instance so the instance can call Google Cloud APIs. I am assuming you have an understanding of the basic operation of service accounts and want to spend some time talking about about two things: service account impersonation and service account placement.

Service account impersonation

Service account impersonation is the temporary assertion of the identity of a service account to perform tasks requiring the privileges of that service account. This is similar to the sudo command on Linux, the Run as capability on Microsoft Windows, or AssumeRole on AWS. To impersonate, the impersonator requests short term credentials of the service account to be impersonated.

Here are the main things you need to do to perform service account impersonation.

• Enable the IAM Service Account Credentials API to permit the creation of the short term credentials provided for impersonation.
• In the permissions for the service account to be impersonated, grant the Service Account Token Creator role to the impersonator (either a user or another service account). It’s better to grant the role at the level of the impersonated service account rather than granting the role to all service accounts in order to promote the principle of least privilege.
• Use the--impersonate-service-account with a service account email address in your gcloud command to perform the impersonation. If the command is failing, you can add the --verbosity=debug option to generate additional information that may help you resolve the problem.

Service account placement

Service account placement refers to the location of service accounts used by projects. You can create service accounts in a decentralized manner by placing the service accounts in the projects in which they are used. This approach is easier in terms of initial administrator overhead. The project owner creates service accounts as needed and assigns the appropriate permissions within the project. The disadvantage of decentralized placement is that auditing becomes more difficult because the service accounts are spread out across multiple projects.

With centralized placement, all service accounts are created in a central project. Other projects use the service accounts in a hub-spoke model as shown in the figure below.

With the centralized approach, auditing is easier because all of the service accounts are in one project. If you want to go with a centralized approach, here are the steps to follow.

• Create the “hub” project and disable the constraint named Disable Cross-Project Service Account Usage. In other words, you want to enable cross-project service account usage with service accounts in the hub project.
• In each of the spoke projects, identify the service accounts of the service agents that will need to access the service accounts in the hub project. For example, the Compute Engine service agent in a project has the service agent service account of: service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com. Also enable the Disable Service Account Creation constraint for each spoke project to prevent new service accounts from created in the spoke projects which would result in service account “sprawl.”
• For each service account in the hub project, grant the service agent service accounts in the spoke projects the Service Account User and Service Account Token Creator roles.

Labs

If you would like to learn more about OS Login and service accounts, check out the GitHub repository I created. You’ll find a lab on OS Login and two labs on service accounts.

Conclusion

You can use both OS Login as well as service account impersonation and placement to provide additional governance in your Google Cloud organization. OS Login allows you to control access to your Google Cloud Linux instance and a consistent POSIX group experience between Google Cloud and your other environments.

Service account impersonation allows you to temporarily obtain privileges when you need them. A centralized service account placement strategy can help you avoid service account “sprawl” and make it easier to audit the service accounts in your organization.