Multi Cloud Secrets Rotation Explained

Good day. It's Tuesday, Aug. 20, and in this issue, we're covering:

• Multi Cloud Secrets Rotation Explained

• How Figma Migrated onto K8s in Less Than 12 months

• Starting Sep 16, 2024: CLI password auth for Docker Hub ends with SSO enforced

• How to Expose Kubernetes Apps Using the Gateway API

• We Can Resize Pods without Restarts Or Can't We?

• Generative AI For Beginners - 18 Lessons

You share. We listen. As always, send us feedback at [email protected]

Use Case

Multi Cloud Secrets Rotation Explained

Each cloud providers—like AWS, Azure, and Google Cloud—has its own way of handling secrets.

This illustration will help simplify the understanding of how these workflows operate across different clouds.

AWS:

• A rotation event triggers AWS Secrets Manager to start the secret rotation process.

• Secrets Manager creates a new version of the secret and initiates a multi-step rotation.

• It calls a custom Lambda function that updates all dependent resources, such as Kubernetes clusters or APIs, with the new secret.

• The new secret version is then activated and stored in Secrets Manager, ensuring all resources use this updated secret.

Azure:

• A rotation event occurs, triggered by Azure Key Vault detecting a secret nearing its expiry.

• This event is passed to Azure Event Grid, which routes it to an Azure Function App.

• The Function App regenerates the secret and updates it in Key Vault.

• If needed, the new secret is stored in a Storage Account for auditing or further processing.

• The updated secret is then distributed to all dependent resources, such as SQL databases, Kubernetes clusters, or APIs, and becomes the active secret.

GCP:

• The process starts with a rotation event, triggered by Cloud Scheduler or Pub/Sub.

• A Google Cloud Function, designed for secret rotation, handles the process.

• The function generates a new secret, updates it in Secret Manager, and associates it with the relevant service accounts and IAM roles.

• The new active secret is then distributed to all dependent resources, ensuring that Kubernetes clusters, APIs, and other services are updated to use it.

Not keeping up with these rotation steps can make your systems unsafe, so always make sure your secrets are updated and secure.

p.s. if you think someone else you know may like this newsletter, share with them to join here

Tool Of The Day

Try it out !

Trends & Updates

Resources & Tutorials

Picture Of The Day

AWS classic console:

Did someone forward this email to you? Sign up here