Generated etcd.pem not following expiration configured in cluster.yaml

[iherbmatt]

Hello,

I recently downloaded kube-aws 0.9.8 and generated a fresh set of credentials using the following command:

kube-aws render credentials

Beforehand, I set both Cert and CA certificate expiration to 3650 days (10 years). What I notice was that all certificates but the etcd.pem cert were generated to expire in 2027. The etcd.pem certificate was set to expire in 365 days.

In order to determine the expiration I'm using the following:
openssl x509 -enddate -noout -in etcd.pem
Here's the output:
notAfter=Aug 30 05:40:25 2018 GMT

It seems this is a bug? It's the only certificate that expires this soon. What would be the result of this certificate expiring?

Thank you,

Matt

[mumoshu]

@iherbmatt Good catch!

Probably it is a bug. The value seems to have been hard-coded to 365 days for a year.

https://github.com/kubernetes-incubator/kube-aws/blame/a2daf1a95a40a6326f38fb1c244b0d8a6b790289/core/controlplane/config/encrypted_assets.go#L189-L191

According to the commit history, I believe there's no specific reason to hard-code, especially to 365 days. I'm more than ok to "fix" the expiration to be read from tlsCertDurationDays provided via cluster.yaml, similarly to other certs.

Would you be ok with that?

[iherbmatt]

I think that would be a good idea - it would definitely make the configuration more consistent. Thank you! *Matt Poland | Software Developer* *iHerb Inc - Natural Products & More* *www.iherb.com <http://www.iherb.com> | matt-p@iherb.com <matt-p@iherb.com>*

…

On Wed, Aug 30, 2017 at 12:36 AM, KUOKA Yusuke ***@***.***> wrote: @iherbmatt <https://github.com/iherbmatt> Good catch! Probably it is a bug. The value seems to have been hard-coded to 365 days for a year. https://github.com/kubernetes-incubator/kube-aws/blame/ a2daf1a/core/controlplane/ config/encrypted_assets.go#L189-L191 According to the commit history, I believe there's no specific reason to hard-code, especially to 365 days. I'm more than ok to "fix" the expiration to be read from tlsCertDurationDays provided via cluster.yaml, similarly to other certs. Would you be ok with that? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#892 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AWH4rsNE37Uk0-FCvX720qAFiawBoLGvks5sdRENgaJpZM4PG5ep> .

-- *The information contained in this message is the sole and exclusive property of **iHerb Inc.** and may be privileged and confidential. It may not be disseminated or distributed to persons or entities other than the ones intended without the written authority of **iHerb Inc.* *If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it. Do not open any attachments. Please delete it immediately from your system and notify the sender promptly by e-mail that you have done so.*

[mumoshu]

@iherbmatt Thanks for the confirmation 👍
The fix is on-going in #895

[whereisaaron]

Bugger I wish I had seen your issue earlier @iherbmatt! I just had a cluster created with an older that 0.9.8 version of kube-aws go haywire a couple hours ago due the etcd cert expiring after one year instead of three like I had specified in cluster.yaml. I had to quickly roll and install a manual replacement certificate! Thanks for fixing this @mumoshu. I checked my 0.9.9 clusters and don't see the problem there.

[iherbmatt]

How did you fix it? kube-aws update? *Matt Poland | Software Developer* *iHerb Inc - Natural Products & More* *www.iherb.com <http://www.iherb.com> | matt-p@iherb.com <matt-p@iherb.com>*

…

On Sun, Jan 7, 2018 at 10:24 PM, Aaron Roydhouse ***@***.***> wrote: Bugger I wish I had seen your issue earlier @iherbmatt <https://github.com/iherbmatt>! I just had a cluster created with an older that 0.9.8 version of kube-aws go haywire a couple hours ago due the etcd cert expiring after one year instead of three like I had specified in cluster.yaml. I had to quickly roll and install a manual replacement certificate! Thanks for fixing this @mumoshu <https://github.com/mumoshu>. I checked my 0.9.9 clusters and don't see the problem there. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#892 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AWH4rqwjDBhhQvyOb5-Ge1YLo5rDHHAnks5tIbS1gaJpZM4PG5ep> .

-- *The information contained in this message is the sole and exclusive property of **iHerb Inc.** and may be privileged and confidential. It may not be disseminated or distributed to persons or entities other than the ones intended without the written authority of **iHerb Inc.* *If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it. Do not open any attachments. Please delete it immediately from your system and notify the sender promptly by e-mail that you have done so.*

[whereisaaron]

@iherbmatt I issued a new certificate, manually installed it in '/etc/etd2/ssl', and restarted etcd with systemctl.

That is not perfect because I imagine a kube-aws update that rolled etcd nodes will install the old certificate again. But I think in this old kube-aws version etcd node are masked from and kube-aws update changes.

[iherbmatt]

I've not used kube-aws update for handling certificates, but I think you can use it to auto-generate new certificates and then redeploy the new set for another "year" if needed - if you wanted to continue using the old version of kube-aws. *Matt Poland | Software Developer* *iHerb Inc - Natural Products & More* *www.iherb.com <http://www.iherb.com> | matt-p@iherb.com <matt-p@iherb.com>*

…

On Mon, Jan 8, 2018 at 9:59 AM, Aaron Roydhouse ***@***.***> wrote: @iherbmatt <https://github.com/iherbmatt> I issued a new certificate, manually installed it in '/etc/etd2/ssl', and restarted etcd with systemctl. That is not perfect because I imagine a kube-aws update that rolled etcd nodes will install the old certificate again. But I think in this old kube-aws version etcd node are masked from and kube-aws update changes. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#892 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AWH4rr5bo4vf5kBO03lJJea3B9MUfiZ0ks5tIldxgaJpZM4PG5ep> .

-- *The information contained in this message is the sole and exclusive property of **iHerb Inc.** and may be privileged and confidential. It may not be disseminated or distributed to persons or entities other than the ones intended without the written authority of **iHerb Inc.* *If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it. Do not open any attachments. Please delete it immediately from your system and notify the sender promptly by e-mail that you have done so.*

[whereisaaron]

@iherbmatt yeah that occurred to me, but only for one year. I'd have to try using a new kube-aws version to generate it. As unlikely as it sounds, openssl was easier 😄

create-new-etcd-cert.sh

#!/bin/bash
# Generate a new etcd certificate using same CA
set -e

# Must be run in credentials folder
create_cert()
{
  local u="$1" subject="$2" days="$3"

  if [[ -z "$days" ]]; then
    days=1095
  fi
 
  if [[ ! -f ${u}.pem ]]; then
    echo "Creating ${u}.pem for $subject ($days days)"
    openssl genrsa -out ${u}-key.pem 2048
    openssl req -new -key ${u}-key.pem -out ${u}.csr -subj "$subject" -config etcd-new-openssl-config.cnf
    openssl x509 -req -in ${u}.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out ${u}.pem -days $days -extensions v3_req -extfile etcd-new-openssl-config.cnf
    rm ${u}.csr
  else
    echo "${u}.pem already exists"
  fi
}

umask 0077

create_cert etcd-new "/O=kube-aws/CN=kube-etcd"

etcd-new-openssl-config.cnf

[req]
req_extensions = v3_req
distinguished_name = req_distinguished_name
[req_distinguished_name]
[ v3_req ]
keyUsage = digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alternate_names
[ alternate_names ]
DNS.1 = *.ap-southeast-2.compute.internal
DNS.2 = *.ec2.internal