Skip to content

Latest commit

 

History

History
67 lines (50 loc) · 2.84 KB

ami-selector.md

File metadata and controls

67 lines (50 loc) · 2.84 KB
Raw

Background

The AMISelector field of the v1alpha1 AWSNodeTemplate resource is a key-value map with some special key handling (e.g. aws-ids is used to pass image IDs).

Most relevant to this design document was the name field, which was passed as the name filter to DescribeImages API call. This field was removed as a special case in #2978, as there is a risk that without filtering by owner, AMI impersonation could happen with various risks (e.g. security vulnerabilities, malware such as mining, or cost implications).

While the Name tag is still usable, AMI tags are private to an account (so if you want to use the AWS bottlerocket AMIs, you'd need to tag them yourself in each account that you use)

Solutions

  1. Restore the previous name special case as aws::name and add a new aws::owners special case that is passed as the Owners argument to DescribeImages (this arguments supports both aliases such as self and amazon as well as AWS account IDs). Make self,amazon the default for this solution. aws-ids also becomes available as aws::ids - the aws:: prefixes ensure that there won't be clashes with existing AMI tags.

  2. Create a v1alpha2 AMISelector with a much more flexible type than go's map[string]string and deprecate v1alpha1. The new AMISelector could have an interface much closer to DescribeImages.

An example of this might be:

amiSelector:
  owners:
    - self
    - 1234567890
  name: my-ami
  imageids:
    - ami-abcd1234
    - ami-2345cdef
  filters:
    tag:Version: v1.2.3,v1.2.4
    tag:ThisShouldExist:

I think there's still some discussion for what this should look like, and how closely it should map to DescribeImages (here I've taken the approach that the top-level fields all map to an argument to DescribeImages)

owners would default to self,amazon

  1. Add an AMIOwners list field to v1alpha1 (default ["self","amazon"]) and restore name as a special case.

Recommendations

Solution 1 is pretty much already implemented with #3204 - it's very straightforward, but does create a new special case of owners that would conflict with any existing use of owners as an AMI tag.

Solution 3 provides a workaround to the owners tag conflict but seems unnecessary and inelegant just to provide a way to avoid a theoretical conflict.

Solution 2 is the most work, but removes any of the special cases, and provides a much more flexible approach to AMI filtering in general - by allowing filters other than tag:, users will gain more power.

Decision from Working Group meeting

Implement Option 1 as a short-term fix to the immediate problem, and implement Option 2 as part of a bigger API change that addresses similar improvements to security group and subnet selectors.