How Engineering Teams Can Address Cloud Infrastructure Challenges and Trade-Offs


In this article, Ev Kontsevoy, CEO & co-founder, Teleport, examines the security challenges that engineering teams face when accessing cloud computing environments. He reviews the current problems of infrastructure security, the common ways of addressing these problems, aka trade-offs, and looks into the new generation of solutions that are gaining traction.

Infrastructure Access Overhead

Engineering teams are always under pressure to deliver new features and address bugs. They need access to computing such as Linux boxes, Kubernetes clusters, databases, monitoring dashboards, etc. To a security professional, all of these resources represent an ever-growing attack surface area. 

Granting access to modern computing environments is a multi-step process:

  1. Connectivity: An encrypted network connection must be established first. 
  2. Authentication: Only authenticated clients must be able to connect to a protected resource.
  3. Authorization: Clients must only be allowed to perform a subset of actions.
  4. Audit: There must be a historical and a live view of what’s happening and who is responsible.

Configuring every single network socket of every single computing resource for the best possible security is a laborious task. In addition to the large and constantly changing amount of computing resources needing protection, there is also a growing number of engineers who need access. 

Learn More: What Is Multicloud Infrastructure? Definition, Components, and Management Best Practices

Security Trade-Offs

The popular strategies to tame the complexity of secure access come with trade-offs. Let’s take a look at the most common ones:

  • Shared credentials: A security team may carefully configure every computing resource for remote access. But to cut on overhead, they configure access only for the “admin” user whose credentials are stored in an encrypted vault and used by engineers when needed.
  • Relying on the network perimeter: The security within a private network is relaxed, and authentication is only performed at a network boundary using a VPN-like solution.
  • Access bureaucracy: The attack surface area is reduced by making certain resource types, like SSH, not accessible by engineers at all.

These trade-offs present numerous problems:

  • Shared credentials can be stolen and even remain on an engineer’s laptop after she changes employers. Shared aliases do not create a robust audit trail because different users will blend behind the same shared “admin” account.
  • Relying on the network perimeter does not offer enough granularity for permissions for individual resources and also does not allow for a proper audit trail for each resource.
  • Access bureaucracy limits engineering productivity and creates incentives for engineering teams to be building backdoors for themselves.

Learn More: The State of Enterprise Cloud Migrations Spring/Summer 2021

Emerging Solutions

The buzzwords to pay attention to are identity, zero trust, and access plane. 

Identity-based access means moving away from shared accounts. Every user must log in as herself. However, configuring every server and every database for all employees of an organization would be impractical. Instead, identity-based access works by having a user authenticate against single identity storage, receive some sort of an access token, and then use this token to access computing resources.

Zero trust means moving away from network perimeter security. A computing environment built on zero trust principles means that every resource behaves as if it was running on a publicly accessible IP address. Every resource uses encryption, performs authentication and authorization, and maintains its own audit log. This approach forces users to authenticate over and over again. But if zero trust is combined with identity-based access, this allows users to re-use the same token over and over with all resources.

The access plane concept builds on top of identity and zero trust. It allows organizations to let go of the access bureaucracy and consolidate access administration in one place:

  • Creates a single access point for all engineers, all resources types, across all environments.
  • Enforces identity-based access for all resources and people. It uses certificate-based authentication and authorization and therefore acts as a certificate authority of an organization.
  • Automatically creates certificate-based connections to all resource types, even if they do not natively support it. This removes the overhead of having to configure every resource type separately.
  • Maintains the centralized audit log, creating a real-time and historical view of all events across all resources in all environments.

An access plane is a combination of an identity-aware proxy, a certificate authority, and a protocol-aware “sidecar” for every resource type, tied to a centralized audit log. It is the glue that connects together identities of people and computing environments, along with all resources running in them. 

Advanced Techniques

There are additional improvements to security that can be made. One recommendation is to implement the principle of least privilege.

In practice, it means eliminating “root” type accounts. Nobody should have absolute access to everything. 

Engineers are already used to the idea that nobody should be able to launch new code into production by himself; instead, a peer code review is required. A similar idea lies behind an advanced access technique called “access requests”:

What if an engineer could create a “git pull request” requesting temporary access to critical production infrastructure? Then her peers would review and approve such requests, granting her temporary access with solid security and compliance guarantees.

In practice, this works by an engineer (let’s use Alice from the above example) requesting to be placed into a privileged group for a specific amount of time, also providing a reason for access. The access plane will forward the request to her peers (or to a dedicated security team) via Slack (or another workflow tool), where her request can be approved or denied.

Learn More: Public Cloud Total Cost of Ownership: What You Should Know


The availability of an access plane renders what was once an insurmountable task a practical and accessible reality for everyone — with little overhead and at affordable cost.

For years, industry-leading tech companies have employed the best talent to develop and maintain in-house solutions dedicated to the daunting task of implementing connectivity, authentication, authorization and audit logging for every socket in every cloud environment.

Today, recent advancements in access technologies enable any-size companies to apply identity-based authentication and authorization and zero-trust principles for their computing resources.

An access plane also allows more advanced organizations to implement concepts such as the principle of least privilege and temporary privilege elevations with techniques such as access requests or “four eye” policies.

The result is a win-win: simple remote access that frees engineers to be more productive, doesn’t compromise security, enforces compliance and provides visibility into everyone’s behavior. 

Did you enjoy reading this article? Let us know your thoughts on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We would love to hear from you!