Thanks to recent advancements in access technologies, everyone can apply identity-based authentication and authorization and zero-trust principles for their computing resources.
Engineering teams building software are always under pressure to deliver new features, fix bugs, and improve performance. To move quickly, engineers need access to computing resources: servers, Kubernetes clusters, databases, logs, etc.
Granting access to these resources creates a big attack surface area. Consider all attack vectors that exist for a database: An attacker can get SSH access to a database machine, or via a Kubernetes API, or via a compromised Web user interface, or even via the database’s own socket.
What Is Access?
Granting access to modern computing environments is a multistep process:
- Connectivity. First, an encrypted network connectivity must be established.
- Authentication. Only authenticated clients must be able to connect.
- Authorization. Even authenticated clients must be limited in what they can do based on some criteria.
- Audit. It is important to see what’s happening and who is responsible.
What types of computing resources typically need to be accessed? The usual suspects may include SSH boxes, databases, internal dashboards, Kubernetes APIs, various middleware, etc. Each of these layers uses its own configuration syntax, listens on a socket, speaks its own protocol, and has its own take on concepts such as authentication or role-based access control (RBAC).
Configuring access for every single socket of every single instance of every single environment for the best possible security is a laborious task. It requires significant expertise because every resource type comes with its own unique security considerations. In addition to the constantly growing set of these endpoints, there is also a growing number of engineers who need access.
Implementing best practices for connectivity, authentication, authorization, and audit for every socket of every resource type is extremely hard. A compromise often must be made.
To reduce the security overhead, most organizations rely on the combination of these trade-offs: