We talked about IAM in the past 3 posts, identities in IAM, manage users privilege as an IT person and control privilege boundaries. We also talked about how applications use AWS Cognito Identity Pool to get AWS temporary credentials to access AWS resources in early posts of “What I wish I could have learned before starting using AWS Cognito” and “Authentication and authorization with AWS Amplify under the hood”.

We alluded in one of our previous posts that the development team will own a lot of responsibility defining application related resource access control, simply because the dev team owns the infrastructure as code (IaC) responsibility themselves. No matter how security-savvy and security-educated a development team is, the central security team still needs some control, some kind of “trust but verify”.

The team recently released Teleport 6.2. This post will walk you through some of the new features and additions included in this release. This release has a few breaking changes. If you’re currently running Teleport on AWS using DynamoDB, we would advise waiting for 6.2.1 before upgrading.

Open Source software provides the community source code that anyone can inspect, modify, and enhance. OSS is so ubiquitous that it’s even on other planets. This post is for the people who run these projects.

This year we launched Teleport Cloud, a new service for providing a hosted version of Teleport Access Plane. One of the first problems the team had to tackle was how to secure the new infrastructure properly, and the team wanted to ensure the best possible results by engaging in an independent audit. As with the Teleport core product, we engaged with Doyensec to provide an independent security audit of our production environment.

Making frequent changes to cloud applications running in production is the de-facto standard. To minimize errors, engineers use CI/CD automation, techniques like code reviews, green-blue deployments and others. Git pull requests often serve as a foundational component for triggering code reviews, Slack notifications, and subsequent automation such as testing and deployments. This automated process enforces peer reviews and creates enough visibility to minimize human error.

Writing a web application that supports securely logging into a website and managing your credentials is a surprisingly difficult task. You have to develop a way to manage sessions, understand how browsers store state (cookies), learn a cryptographically safe password storing technique (like bcrypt), all the while making sure you mitigate common web security vulnerabilities like XSS and CSRF.

Teleport has supported multi-factor authentication (MFA) for a while now, via Authenticator Apps (TOTP) and Hardware Tokens (U2F) such as YubiKeys. But this support was pretty limited: you could only choose one MFA protocol and users could only register one device. If a user lost their device, they would be locked out and need an account reset by the administrator. So, for Teleport 6.0, we’ve reimplemented the MFA support to make it more flexible.

Security Assertion Markup Language (SAML) 2.0 is one of the most widely used open standard for authentication and authorizing between multiple parties. It’s one of the protocol that give users the single sign-on (SSO) experience for applications. The other adopted open standard is OAuth and OpenID. Of the two, SAML 2.0, released in 2005, remains the 800 pound gorilla in Enterprise SSO space. This post provides a detailed introduction on how SAML works.

We now live in an era where the security of all layers of the software stack is immensely important, and simply open-sourcing a code base is not enough to ensure that security vulnerabilities surface and are addressed. At Teleport, we see it as a necessity to engage a third party that specializes in acting as an adversary, and provide an independent analysis of our sources.