Description
Placing a private key in user_data_base64 can leave the secret in code, Terraform state or instance user data. Base64 is encoding, not encryption: anyone who can read the value can recover its original contents.
If a disclosed private key remains valid for authentication or signing, it can be misused on systems that trust it. Distinguish private keys from public certificates; not every certificate is a secret.
Potential impact
- Disclosure of a real private key can allow misuse of its authentication or signing authority.
- Reusing the same key across systems can increase the number of affected services.
- Keys copied into code and deployment materials are difficult to replace and recover.
Remediation
- Remove private keys from user data and use a secret-management service such as Secrets Manager or Parameter Store
SecureString. Allow the workload to retrieve only the secrets it needs. - Identify consumers of an exposed key, replace it, and revoke trust or authentication permissions for the old key.
- Launch configurations cannot be edited in place. Prepare a replacement configuration and plan instance replacement; prefer launch templates for new configurations.
Examples
These are partial examples of a legacy launch configuration. Supply the AMI lookup and instance requirements separately.
Before
resource "aws_launch_configuration" "app_launch_config" {
image_id = data.aws_ami.ubuntu.id
instance_type = "m4.large"
user_data_base64 = "LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpzb21lS2V5"
}
The value decodes to a private-key opening marker and someKey; it is an illustrative string, not a complete valid private key. Encoding a real key the same way would not protect its secrecy.
After
resource "aws_launch_configuration" "app_launch_config" {
image_id = data.aws_ami.ubuntu.id
instance_type = "m4.large"
}
This removes the entire user_data_base64 setting. It does not retain initialization instructions, so configure any required bootstrap tasks separately without embedding secrets.