kubernetes-retired/kube-aws

s3, kms, awscli, & kube-aws: time to update coreos/awscli?

flah00 opened this issue · 2 comments

Problem

The kube-aws project makes extensive use of the quay.io/coreos/awscli:master image. It's slightly quirky, in that it offers no entrypoint and hasn't been updated in two years. This differs significantly from the amazon/aws-cli image, which is current and its entrypoint is aws. The age and quirks of coreos/awscli have caused me some recent headaches.

Solution

Migrate from quay.io/coreos/awscli to amazon/aws-cli

Knock on effects of the problem

Where I work, our kube-aws bucket must be KMS encrypted. To use KMS and S3, you must use signature version s3v4.

It seems that although the quay.io/coreos/awscli:master image supports this signature version, it's not the default . To enable this feature, for, you must run aws configure set default.s3.signature_version s3v4. Or you must start with an ~/.aws/config file that already includes [default]\ns3=signature_version=s3v4\n.

To work around this, I've had to commit a new layer atop the quay/awscli image, with the config file in place. And then I had to shoehorn that image into the etcdadm environment file, ie

etcd:
...
  customFiles:
    - path: /etc/update-etcdadm-image.sh
      permissions: 0755
      owner: root:root
      content: |
        #!/bin/sh
        env=/var/run/coreos/etcdadm-environment
        if `grep -q ETCDADM_AWSCLI_DOCKER_IMAGE $env`; then
          exit 0
        else
          echo ETCDADM_AWSCLI_DOCKER_IMAGE=quay.io/MINE/awscli:master >>$env
        fi
  customSystemdUnits:
    - name: update-etcdadm-environment.service
      command: start
      runtime: true
      content: |
        [Unit]
        Description=Change env var ETCDADM_AWSCLI_DOCKER_IMAGE
        After=cfn-etcd-environment.service
        Wants=cfn-etcd-environment.service
        [Service]
        Type=oneshot
        RemainAfterExit=true
        ExecStart=/etc/update-etcdadm-image.sh

I back this, actually where I work we've had to do something similar a year or two ago but never committed upstream. I'll review what we have and see if it's appropriate for upstream push, and if it is make the change.

I'd probably cut it into the 0.15.x, 0.16.x and 0.17.x (master) releases. Does that work for you?

That works for me @dominicgunn, thanks for the quick reply