Comment 0 for bug 1865947

Cloud-init persists world-readable instance metadata in /run/cloud-init/instance-data.json and a read-only root /run/cloud-init/instance-data-sensitive.json.

Any sensitive metadata provided by a cloud platform's metadata services should be redacted from instance-data.json by cloud-init if that DataSource class defines a list of sensitive metadata key names as a a class attribute "sensitive_metadata_keys".

Cloud-init matches redacts the correct sensitive keys if discovered when crawling metadata, but it then writes the unredacted information to the world readable /run/cloud-init/instance-data.json
instead of the root read-only /run/cloud-init/instance-data-sensitive.json.

See the related code at:
https://github.com/canonical/cloud-init/blob/master/cloudinit/sources/__init__.py#L318-L323

This can affect any Datasource if either of the following apply:
 1. It is not DataSourceEc2 and the platform metadata contains a sensitive 'security-credentials' key
 2. It is a private subclassed DataSource that is not present in cloud-init upstream but has set the class attribute sensitive_metadata_keys to be something other that sensitive_metadata_keys = ['security_credentials']

The end result is the sensitive keys they thought they were redacting, end up being published to the world-readable /run/cloud/instance-data.json.

In practice, the only cloud we are aware of that provides a 'security-credentials' key in metadata is Ec2 on VMs that are created with an IAM profile. This security exposure on Ec2 only is also negated because the utility that crawls ec2 metadata service also happens to skip 'security-credntials' when crawling metadata so cloud-init doesn't see that key anyway.

See this code:
https://github.com/canonical/cloud-init/blob/master/cloudinit/ec2_utils.py#L87-L89