Zarządzanie sekretami i konfiguracją w chmurze

A database password baked into an image leaks to anyone who pulls it. Inject secrets at runtime instead, never at build time. 🔐

Plain settings like a model path are config. Sensitive values like API keys are secrets. Both stay outside the image, handled differently.

Non-sensitive settings ride in as environment variables at deploy time. The same image then behaves differently in staging and production.

Your app reads those values with os.environ. Provide a sensible default so the code still runs locally without every variable set.

Real secrets belong in a secret manager like AWS Secrets Manager or Google Secret Manager. It encrypts, versions, and audits access.

You attach a secret by reference, and the platform mounts the value at runtime. The secret never appears in your deploy command.

A secret can land as an environment variable or a mounted file. Certificates and long keys are often cleaner read from a file path.

Give the service account only the secrets it truly needs. This least privilege rule shrinks the blast radius if a token ever leaks.

Pin secrets to a version like latest, then rotate by adding a new version. New instances pick it up with no image rebuild needed.

Logs are stored and widely readable, so a printed key is as good as public. Scrub secrets from output and from error traces alike.

With config and secrets external, a single image runs everywhere. You change behavior by swapping variables, not by rebuilding.

Let us check the safe way to handle an API key.

You split config from secrets, injected both at runtime, used a secret manager, and rotated safely. One image now runs anywhere. 🔑