Terraform-provider-aws: Launch Template not accepting User Data

[hashibot[bot]]

_This issue was originally opened by @RichCranney as hashicorp/terraform#18665. It was migrated here as a result of the provider split. The original body of the issue is below._

---

Terraform Version

Terraform v0.11.3

+ provider.aws v1.31.0

+ provider.null v1.0.0

+ provider.template v1.0.0

Terraform Configuration Files

data "template_file" "test" {

  template <<EOF

    mkdir /tmp/test

  EOF

}



resource "aws_launch_template" "test" {

  name = "test"

  image_id = "ami-xxxxx"

  instance_type = "t2.micro"

  user_date = "${data.template_file.test.rendered}"

  key_name = "MyKey"

}

Expected Behavior

Launch template should have created with User Data

Actual Behavior

Failes to create with following error

'''

• module.compute.aws_launch_template.test: 1 error(s) occurred:

• aws_launch_template.test: InvalidUserData.Malformed: Invalid BASE64 encoding of user data.

  status code: 400, request id: 0523fc12-cd5a-410a-9548-2a648beac75f
  

'''

Steps to Reproduce

terraform apply

With above code

[RichCranney]

This is not a provider issue as I can manually add the user data into the launch configuration within the AWS console.

[tracypholmes]

Hi @RichCranney! I was not able to reproduce this error. I am including the configuration file that I used. Could you let me know what's different or if you are still receiving errors? If you are still getting errors, please let me know what changes to make. Thanks!

terraform {
  required_version = "0.11.3"
}

provider "aws" {
  region  = "us-east-1"
  version = "1.31.0"
}

data "template_file" "test" {
  template = <<EOF
    mkdir /tmp/test
  EOF
}

resource "aws_launch_template" "test" {
  name = "test"
  image_id = "ami-094fb6bd5eb0f5790"
  instance_type = "t2.micro"
  user_data = "${data.template_file.test.rendered}"
  key_name = "MyKey"
}

[mbainter]

I ran into this problem, but I solved it by wrapping it with a base64encode() call like so:

resource "aws_launch_template" "test" {
   ...
  user_data = "${base64encode(data.template_file.test.rendered)}"
}

My user-data was fairly lengthy - so maybe beyond a certain size base64 encoding is required? Alternately, perhaps it requires it when certain characters are present? (In my test example it was a windows machine with a powershell script, so there were a lot of symbols in use)

[RichCranney]

@mbainter, that was exactly the issue, thank you so much. I had tried base64 but not base64encode.

Works like a charm.

[tracypholmes]

@RichCranney - I am glad to hear that's working for you! We're going to close this issue for the moment. Thanks!

[davehowell]

@tracypholmes I don't think your test case really does succeed, even though you don't see the same error. It appears to work because your userdata doesn't use any characters outside those used in base64 encoding. I strongly suspect that your userdata would be decoded into something invalid. So while the terraform stack may have planned/applied successfully, the userdata script probably failed. When the userdata is executed on the EC2 instance it will be decoded. I tried decoding mkdir /tmp/test, (the spaces and newlines are skipped by base64 decoding) and it gives Gbf^ This page is useful https://www.base64decode.org/ What happens when you try and run Gbf^ will depend on the platform, but will probably an error like "command not found".

If you are passing plaintext into userdata, @mbainter suggestion is the right thing to do. There are other ways to construct userdata that will already be base64 encoded, so the behaviour of Terraform aws provider is correct here, it needs to be up to the end user whether or not to apply the encoding. You wouldn't want to base64 encode twice, because the single decoding would also result in something invalid.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!