In Blog, Google Cloud Platform (GCP)

Google Compute Engine

The Revolutionary Impact of Google Compute Engine

Since its release in 2012, Google Compute Engine (GCE) has become one of the leading Infrastructure-as-a-Service (IaaS) platforms. GCE is enabling a whole set of businesses to operate in a new, more efficient way. With capabilities such as low cost instances and shared core machines to handle long-term workloads, Google is providing unique capabilities to their customer base.

Companies that used to have on-premises data centers or network infrastructure can largely shift that to GCE. New organizations have it even better, as they don’t need to make an adjustment; they can get right into building and managing their own server infrastructure. GCE becomes their infrastructure on an as needed basis.

The benefits of IaaS are huge. Organizations no longer need to invest the time or money to build their own infrastructure. Google Compute Engine is changing the game for businesses of all sizes.

Merging GCE with IT

modern office cloud solutions

The challenge for most organizations is not how they can leverage GCE, but how they can merge it with their existing IT process and organization, creating a so called “hybrid” environment.

For many companies that already have an existing network infrastructure, GCE can live outside of their normal processes and systems and that can limit the benefits. GCE for many of these organizations ends up being an adjunct to their infrastructure rather than being integrated into it.

For other organizations that don’t have an existing infrastructure, GCE becomes a core part of their network infrastructure. However, they still may treat it as separate and distinct from their on-premises network or SaaS applications. Again, this potentially limits the benefits they could get from GCE. Either way, Google Compute Engine needs to be integrated into the core processes and systems for an IT organization.

To bring GCE into the IT fold, arguably the most critical place to start is with directory services. Whether you have an existing directory or not, Google Compute Engine server users need to be centrally controlled and managed as well as your other users and IT resources. There are a number of reasons for this:

  • Centralized user control – There should be one central system to add, terminate, or modify user privileges. Having multiple locations where users can be managed is asking for mistakes. A user may be terminated in one system, but not another. Or, a user may not have all of the access they need, causing additional IT support requests.
  • Security  GCE server users will potentially be accessing mission critical applications and data. A terminated user that retains access to a core GCE server is a security risk. Further, a central directory services system ensures that there is a central place to audit access control which is a requirement for many security regulations.
  • Efficiency  With the number of devices and IT applications rising, users need more tools than ever to do their jobs. Manually connecting users to all of the resources they need is time consuming. Helping users reset their passwords, manage their keys, or keep their accounts secure ends up costing IT admins a lot of time.

A central directory service solves a number of needs within any organization. Connecting that directory to your GCE environment integrates it into your core IT processes.

Google Compute Engine and Directory Services

Google Identities Cloud

The challenge, of course, is how to actually connect GCE to directory services. Because the GCE environment is in the cloud and not on-premise, that presents some interesting technical problems. If an organization has an existing directory, they often do not expose it to the Internet or allow Internet facing systems to route to the directory. These are done for security reasons. Not all directories will also easily connect to all platforms. For instance, connecting a Linux system to Active Directory® is not trivial. These technical challenges and others generally force GCE users to manually manage users.

With the advent of Directory-as-a-Service® (DaaS) solutions, the process of connecting Google Compute Engine resources to a directory is now simple and straightforward. There are two scenarios to review: the case of connecting GCE to an existing Active Directory user store and the path of managing GCE with a new user directory.

Connecting GCE to Active Directory

identity management market alternative

DaaS solutions (often referred to as a cloud-based directory) such as JumpCloud can bridge your Active Directory user store to Google Compute Engine. In this scenario, users are automatically mirrored in a cloud-based directory through a small agent that lives on the AD server. As a result, the cloud-based directory is kept in sync with AD to ensure that any changes are automatically reflected in the DaaS solution. From there, the DaaS solution is then connected to the GCE servers either via an agent or a simple config pointing to the DaaS solution as the authentication point (via LDAP). As a result, the cloud-based directory now contains all of the users that need access to GCE and a mechanism to control authentication and authorization on those GCE servers. Note, with the Directory-as-a-Service agent, IT admins can also manage GCE servers, gaining the ability to centrally execute commands and tasks via commands or scripts. The mechanism to control access can be done via the native user access controls per platform or via LDAP.

Once the cloud-based directory is connected to AD and the GCE servers, the process to manage server access control is as follows. A list of users appears in the DaaS console. These users can easily and quickly be connected to GCE servers. This can be done one at a time or in bulk through Groups (the connection between groups of users and servers). Simple clicks in the interface provision or deprovision access. Finer-grained controls can setup and manage groups or admin/root/sudo level access. It should be noted that any changes in AD automatically flow through to the GCE server fleet. For example, a user that is terminated in AD is automatically terminated in all GCE servers.

Connecting GCE to your on-premise Active Directory user store can simplify your user management, increase security, and provide greater control. To learn more about how to connect GCE to Active Directory, see the JumpCloud web-site.

Connecting GCE to a New Directory

Some organizations do not have a central directory such as Active Directory or LDAP or do not want to co-mingle their GCE users with their central user store. For these organizations, creating a new directory is the right answer. Spinning up and managing a directory, though, is a lot of work and overhead. Leveraging a SaaS-based directory service is an easier, more cost-effective, path.

The other side of a Directory-as-a-Service solution is the ability to create and run directory services in the cloud. IT admins look at DaaS as a plug-and-play directory services module for their GCE infrastructure. Users are populated in the cloud-based directory through an easy-to-use web interface. From there, GCE servers are connected to the cloud-based directory. The servers can be connected via a lightweight agent that is installed on each server or by configuring the server to connect to the DaaS solution via LDAP. Both methods provide for authentication and authorization control over user access.

If IT admins also desire management control over the GCE server fleet, the agent provides this capability. Commands or scripts written in any language supported by the server can be executed on each server. They can triggered ad hoc, scheduled, or triggered by events. Workflows involving multiple sets of servers can also be created, and triggered by a remote webhook.

Another critical capability of DaaS is multi-factor authentication on Linux servers. With major organizations keeping their most critical digital assets at Google Compute Engine, adding another layer of access control can be a smart step. The second factor is provided by Google Authenticator on a user’s smartphone.

Connecting GCE to a strong cloud-based directory automates a number of the manual user management steps, increases security, and locks down control over your GCE infrastructure.

Learn More About Merging Google Compute Enginejumpcloud learn more demo

Integrating your GCE infrastructure into your IT processes is critical. By connecting your GCE cloud servers to directory services, your organization has the opportunity to fully leverage GCE while ensuring that access is securely controlled. Directory-as-a-Service solutions like JumpCloud are enabling this GCE to directory connection. If you would like to learn more about how you can take your GCE infrastructure to the next level, drop JumpCloud a note here.

Recent Posts