Kubernetes is a tool used by many developers and DevOps administrators to deploy and manage containerized applications, and it has become a default tool for container orchestration in many organizations.

This blog is part two of a series about identity-aware access for Amazon RDS. In Part I, we covered how to use OSS Teleport to access Amazon RDS instances running in private subnets. In Part II, we will guide you through the steps to configure single sign-On (SSO) for Amazon RDS with Okta, SAML and Teleport.

"Create cryptographically secure access keys" and "Rotate keys frequently" — These are probably the best security recommendations one can get for bot authentication security. In reality, while these are good practices, they simply aren't enough. First, cryptographically secure keys only prevent simple guessable or brute-force attacks, but the impact is catastrophic if the keys themselves are stolen.

Containers are used for packaging software and all its dependencies before deployment. Before the era of containers, software developers had to deal with compatibility issues during deployment. These could occur when software functions properly during the development phase but fails to function due to dependency issues in the production environment. With containers, however, all the software dependencies used for development can be shipped and used in the production environment.

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.