Securing Access to Your Infrastructure with Teleport
The lack of access control and monitoring creates a significant security risk for companies and opens them up to data breaches that could cost them millions of dollars.
Over the years, companies have relied on traditional approaches like virtual private networks, passwords, private keys, segmentation with role-based access control, etc., as a form of securing their infrastructure, but these methods are usually labor intensive, highly subject to breaches and not future-proof.
The advancement of hackers requires stepping up your security game, and that’s why using an access control system like Teleport, which follows the principle of least privilege, is recommended.
In this article, I’ll highlight different ways Teleport can be used to securely access and monitor your team’s infrastructure (VM, Kubernetes clusters, databases Windows Server) and, as such, expedite your team’s development workflow, productivity and security.
Manage Access to Your Kubernetes Clusters Using SSO
Using the default approach, you’d typically have to create a Kubernetes role object and assign your teammates to it. Teleport enables you to do this, but it goes a step further to support the implementation of a single sign-on (SSO) authentication scheme using any of these SSO providers, thereby removing the need to create separate users for your K8s cluster each time a new teammate joins the company.
Using Teleport to implement SSO authentication on your infrastructure comes with many benefits. Some of my favorites include:
- Enabling development teams to quickly access and invite teammates to their Kubernetes clusters with just a click. This improves security and minimizes theft of login credentials, such as passwords because development teams no longer have to use passwords or private keys to access their Kubernetes clusters.
- Relieving systems administrators from the burden of managing SSH keys or local passwords.
- Serving as a compliant process for onboarding, transferring and offboarding members of a development team. For instance, let’s assume Alice recently joined The Didi Organization as a software engineer. Since The Didi Organization uses Teleport and has already setup connected its infrastructure to the GitHub SSO provider, they’ll be able to add her to the team-a-access role on GitHub, which will automatically give her access to the necessary permissions to complete her tasks on the company infrastructure (a K8s cluster). If Alice transferred from Team A to Team B, she’ll be quickly removed from the team-a-access role on GitHub and added to the team-b-access role thereby losing all privileges given to members of Team A. When Alice leaves the company, she will be removed from the team-b-access role on GitHub, causing her to lose access to the Kubernetes cluster in seconds. Without Teleport, The Didi Organization would spend more time performing all these actions as it would require writing YAML configuration files, running commands on the CLI, updating tons of records, etc., all of which could lead to ineffective access control management.
Learn more about how Teleport users can log into any infrastructure (servers, Kubernetes clusters, databases, web applications and Windows desktops) through GitHub or their organization’s single sign-on (SSO) if using the enterprise version.
Netflix for Your Kubectl Execs
Teleport was built to facilitate identity-based security. This means that people who do not match the specified identity will not be given access to any of your infrastructure, thereby neutralizing security threats and reducing the impact of breaches.
One of the benefits of this security approach is that you’ll know the identity of everyone who has accessed your Kubernetes cluster and can also see the interactions performed on the cluster for security or debugging purposes.
For instance, imagine that one of your teammates (Paul) made some changes to the Kubernetes cluster and then goes out for lunch immediately without realizing the changes he made negatively affected the Kubernetes cluster. You get notified about this error and instead of panicking, you’ll head over to your Teleport Dashboard, view the cluster’s audit log and identify the actions performed on the Kubernetes cluster.
With this new information, you know that Paul’s changes may have caused the issue, but you want to confirm, so you head over to the Session recordings of Paul’s activities, see exactly what he did and make the required changes to fix the issue. Pretty cool, right? I know! With Teleport, debugging and analyzing bugs is now easier than ever.
For context, Teleport’s visibility comes in three formats; session recordings, audit logs, and a live view.
- The session recordings will show you every
kubectlsession by a developer or service account. - The unified audit log shows you all events across all clusters in a single location.
- The live view displays all online clusters, active
kubectlsessions, and access requests.
RBAC and ABAC With the Principle of Least Privilege
Role-based access control (RBAC) and attribute-based access control (ABAC) are the two most popular ways of implementing access control. RBAC permits or restricts access to an infrastructure based on the individual’s role within the organization. In contrast, ABAC restricts or approves requests based on specific attributes (time, location, etc.) of the individual.
RBAC and ABAC have their benefits, as highlighted in the links added above, but they also have certain disadvantages. For instance;
- RBAC can either give individuals too much access, thereby violating the principle of least privilege and potentially exposing sensitive information, or be overly restrictive, thereby causing people to manually request access that will then be granted or denied manually, leading to an increase in the organization’s number of roles and amount of work done.
- With ABAC, you can set up access for a developer to only be able to access the infrastructure or certain resources between 9 a.m. and 5 p.m. But what if a cyberattack or bug occurs at 10 p.m.? The developer will not be able to access the required resources to resolve the issue or may have to manually request for access, and the person who is supposed to grant them access may be off, sleeping or otherwise unavailable.
Teleport doesn’t only make it easier for you to incorporate the good aspects of RBAC and ABAC. It also addresses its cons by including features that allow you to implement the principle of least privilege on your infrastructure while using either RBAC or ABAC.
For instance, when using RBAC the default way, you’d always have to proactively update policy on any data or organizational structure change because RBAC doesn’t future-proof any organizational changes. But when implementing RBAC with Teleport, you don’t need to worry about RBAC’s future-proof limitations as you can grant access to certain resources for a certain period of time and their access to that resource will be terminated after the time has elapsed.
One-Time Privilege Escalation to Infrastructure
With Teleport, development teams can escalate their requests for specific roles or resources inside an infrastructure to ensure they are not left frustrated because they’ve not been given access to the necessary resources they need to fix a bug.
There are so many key things I find fascinating about Teleport’s one-time privilege escalation. To name a few;
- Its ability to allow access requests to be approved or denied via Slack and other supported ChatOps tools. Gone are those days when your only option was to use your CLI or write YAML files.
- The ability to enable a dual authorization (this means at least two people have to approve a request for sensitive resources) to prevent phishing attacks that could compromise your infrastructure. For instance, if Paul wanted to gain access to the dbadmin role, he’d go to their Teleport dashboard, select
dbadmin, add the reason for the request and click on the Send Request button. The security team (let’s call them Didi and Alice) will get notified about this access request by Paul on Slack, review and then approve or deny the request. - Every access request on your infrastructure is captured and can be viewed later by clicking on Audit log on the Teleport dashboard. This is excellent for debugging.
Summary
Teleport doesn’t just enable you to create secure access to your infrastructure, it:
- Employs new ways that make the stressful process of access control management easier (such as SSO implementation).
- Acts as a one-stop shop for all your infrastructure (you can see everything on your Teleport dashboard).
- Gives you complete visibility of everything that happened on your infrastructure making debugging and data breach management easier.
- Allows users to quickly request access to their infrastructure, letting administrators grant access for a short period.
If your team’s access control challenges keep you up at night or are becoming too labor-intensive, then Teleport may be what you need. I’d recommend you check out their case study page as it will help you learn about how Teleport is used by companies in numerous fields and also discover how it would work in your field as well.