Every time I see a base64-encoded SSH key sitting in a user-data script, a small part of my brain turns to static. Sure, it works in development when you’re just firing up a single VM, but once you move to immutable OS images managed by bootc, keeping secrets in cloud-init is a ticking clock. If that image metadata leaks or someone dumps the config, your entire fleet’s access is wide open.

Why static cloud-config is a trap

Cloud-init is powerful, but treating it like a provisioning engine for secrets is a mistake. When you move to bootc, the OS becomes an immutable artifact. If you’re injecting keys, passwords, or API tokens through the cloud provider’s user-data interface, you’re essentially building state into an object that should be stateless. It makes rotation impossible without redeploying, and honestly, you have better tools at your disposal now.

curl -s 169.254.169.254/latest/meta-data/iam/security-credentials/your-role-name

• Use instance profiles for IAM roles instead of hardcoding keys
• Fetch runtime secrets from Vault or Secret Manager only after the system reaches ready state
• Keep your bootc container images strictly for OS configuration, not for environment-specific secrets

Let the runtime handle the heavy lifting

Instead of pre-populating files in /etc, use a sidecar or a dedicated agent to grab what you need once the network is actually up. Most people reach for cloud-init because it’s what they know, but if you treat your instance like a clean slate that earns its permissions from the provider identity, you stop worrying about who might be scraping your user-data. Next time you go to paste a private key into a provisioning script, stop and look at your provider’s SDK documentation for temporary credential exchange instead.