cloud-init and account-expiry

Recently, a new customer asked me to automate a platform-deployment for them because I'd done similar for another organization they do business with.

I generally configure my automation to use #cloud-init to override the AMI's default-user's name (why let attackers know what EC2 account to attack just because it's set to something in the AMI?) Normally, this isn't a problem.

Unfortunately, the new customer bakes a lot of security-settings into their AWS machine images. One of these is setting maximum password-age and expiring the account after N days of inactivity. As a further part of their bake-in, they pre-create the EC2's default user in the AMI (rather than relying on cloud-init to do it at launch-time). Part of that pre-creation specifically exempts their default-user from the aging/expiry.

Didn't really discover any of this until I powered on a testing-cluster that I'd built back in mid-January and got the dreaded, "our account has expired; please contact your system administrator" message.

In looking through both the Red Hat documents and the upstream cloud-init project's documents, it looks like, if I have a stanza similar to:

#cloud-config
system_info:
  default_user:
    name: maintenance

users:
  - default

chpasswd: {expire: False}

It ought to override the security-defaults when cloud-init creates the default user. Unfortunately, this doesn't seem to actually work. Thus far, the only thing that seems to work is to use a Content-Type: multipart/mixed (multipart-MIME) userData document and put a chage … in a #!/bin/bash block that executes after the #cloud-config block executes. I'd like to avoid having to do two-part execution-sequence processe. So, I have to ask, "am I botching the usage of the chpasswd parameter or is cloud-init not doing what it ought to?"