Databases are sensitive resources that need an additional layer of protection and security. Though database servers have built-in authentication and authorization mechanisms, they are not designed for cloud-based, multi-tenant access mechanisms. Managed databases such as Amazon RDS are accessed and administered by different personas with varying levels of access permissions.
I have news to share. Teleport has just secured $110M in Series C funding to keep growing the business that I started with my co-founders Sasha Klizhentas and Taylor Wakefield in 2015. This is exciting for founders and employees, but I think it is also excellent news for all software engineers who are crying out for a better way to manage secure access to their mission-critical cloud infrastructure. More on that below.
This blog post covers some of my favorite settings for configuring the behavior of an ssh client (i.e. what is in the man pages for ssh_config). Whether you are looking to add some additional security constraints, minimize failures, or prevent carpal tunnel, ssh_config is an often underutilized, yet powerful tool. While the examples in this article focus on ssh configurations on unix based systems like linux and macOS, running an ssh server on windows is supported using openSSH.
Every Kubernetes developer’s favorite time of year is just around the corner, Kubecon EU 2022! Whether you’re attending in person in beautiful Valencia, Spain, or watching the conference from your couch at home, here are a few reasons why — if you operate any Kubernetes infrastructure — you need Teleport.
In this post I will be announcing a new open source project: Teleport Connect. It is a dedicated secure web browser for accessing cloud infrastructure. But first, let me explain why we've decided to build it, starting with a bit of historical context. As a kid I have always enjoyed imagining the process of programming to having a conversation with a machine. The REPL loop is the most obvious example of this interaction. As our code grows it no longer fits in a REPL environment.
Running a Kubernetes-based infrastructure is challenging and complex. Administrators often lament how complicated performance optimization and monitoring are, which can lead to problems in production. Additionally, even finely-tuned Kubernetes deployments can encounter sporadic issues. When Kubernetes starts behaving in strange ways, digging into logs can help you uncover breadcrumbs. These contextual hints can help lead you to possible solutions.
SSH was designed in 1995, LDAP was initially developed in 1993, and role-based access control was introduced in 1992. The concept of least privilege was introduced in 1975. With all of these existing technologies, when are modern privileged access management solutions necessary? This is a common question asked when we pitch the idea of modern privileged access management (PAM).
The SSH protocol offers multiple authentication options: passwords, public keys and certificates. Certificate-based authentication is the most secure of them all, but historically, it has been the most complicated to set up. This tutorial guides you through simple steps to configure certificate-based authentication for an OpenSSH server. First, let's consider the differences between certificates and keys. As you can see, an SSH key is a binary proposition.
The modern human likely has profiles on dozens of applications. Whether it’s social media applications, music/video streaming, or workspace resources, each of us must manage accounts that contain personal information. Over time, these siloed applications have become increasingly connected. Twitter allows news sites to directly tweet, Discord searches Facebook for suggested friends, and Jira creates user accounts using Github profiles.
Kubernetes supports several authorization methods, but the best-known and one of the most versatile is RBAC. Role-based access control implements a mechanism for restricting and controlling user access to resources of a system by using roles attached to users.
