Over the last decade, enterprises have accelerated the adoption of the cloud. According to the State of the Cloud report by Flexera, the average annual spend on cloud computing is over $62 million. As enterprises continue to invest in the cloud, AWS, the market leader in cloud computing, is growing at a rapid pace. The rise of cloud computing poses new challenges to enterprise IT. With each department migrating and managing their workloads in AWS, there is a proliferation of accounts, users and roles.

Picture this: unfortunately you had to let one of your engineers go. No matter how many times you tried to tell them, after countless interventions and meetings with the engineering lead, they simply wouldn’t stop using tabs instead of spaces. An absolutely unforgivable offense. A few weeks later, suddenly your production Snowflake database is wiped out. You log on to assess the damages and you check the SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY for every user in the system.

Passwordless is a form of authentication that doesn't require users to provide passwords during login. That much you could glimpse from the name, but how does it work? What are its trade-offs? This blog post will do its best to explain to you how passwordless can be implemented using modern technologies such as Web Authentication (WebAuthn), while at the same time providing better user experience and security than the traditional password-based approach.

As software companies grow, they start to see exponential growth in resources needed to support the business. A startup can quickly go from a few servers and a handful of databases to a sea of Kubernetes clusters. Managing access to all of these resources comes with a myriad of problems. One problem at scale is deciding who can access what resources and how to provide relevant access to those resources on-demand.

Redis is an in-memory data store that stores data in key-value pairs. It’s primarily used as a cache for quick data access, as a database, and as a message broker. Redis doesn’t have a default authentication setup in place exposing it to security vulnerabilities, which if exploited could potentially affect the infrastructure of the entire organization. These security vulnerabilities are what make securing your Redis database so important.

Passwords and other shared secrets are the number one cause of data breaches. The security risks of passwords is widely recognized in the consumer space with the leading tech companies (and competitors) including Microsoft, Google, Apple joining together to create the FIDO Alliance to reduce the over-reliance on passwords. With FIDO, passwords are replaced with more secure, and easier to use biometric and cryptographic authentication.

This post introduces all the features released in Teleport 10. Teleport 10 includes version 10.0, 10.1, 10.2 and 10.3. You can always find an up-to-date status of Teleport releases in our docs. Teleport 10 is the biggest release so far in the history of Teleport in terms of feature sets. Before we dive into all the Teleport 10 features, let me first introduce you to...

A password is a secret, and a secret can be lost, stolen or traded on dark web marketplaces. Most engineers know this, that’s why every SSH tutorial begins with the instructions for disabling passwords and enabling private/public key pairs. But a private key is just another form of a secret. In this article, I will try to explain why all forms of secrets are bad for you.

Many databases were born over 25 years ago, back in the unadulterated times of LAN parties and IRC. SSL was just for banks and sending unencrypted database traffic accounts was just how you did things. When databases use unencrypted connections, it means someone with access to the network could watch all and inspect all database traffic.

In the first part of this blog post, we setup SSL/TLS for a MySQL database, using the built in self-signed certificates. The main problem using out of the box self-signed certificates is that clients can't verify that they're talking to the right database host, and it's not possible to verify the certificate chain. In this post we'll cover upgrading the client connection to VERIFY_IDENTITY and how to use Machine ID to continuously renew certificates.