Open drnic opened 7 years ago
We have created an issue in Pivotal Tracker to manage this:
https://www.pivotaltracker.com/story/show/140624725
The labels on this github issue will be updated when the story is started.
If this involves patching etcd somehow (etcd/etcd-v2.2.0-tls1.2-patch-linux-amd64.tar.gz
), where/how do you construct this patched release and I'll try to create one for v2.3.7 if necessary.
Assuming that the tls1.2 patch is https://github.com/coreos/etcd/pull/5541/files, then I don't see it as having been applied to release-2.3 branch (even though the PR pre-dates v2.3.7). So we still need to patch v2.3.7.
This is something that has been on our minds. It is a little difficult to upgrade etcd
within the context of bosh. To maintain the cluster you cannot jump etcd
versions from say 2.2.0
to 2.3.7
, you have to upgrade each node in the cluster to the next minor, so 2.2.0
to 2.2.1
to 2.2.2
until you get to 2.3.7
. Currently, this means there would have to be an etcd-release
for each etcd
version and to upgrade you would have to bosh deploy
each etcd-release. This is something we would want to avoid as this would require you to not just jump to the etcd
version you want and would require multiple deploys.
In short, we do want to get to a later version of etcd, but we are still thinking about the best way to get there.
As for the tls1.2 patch, we have created a fork with the patch here: https://github.com/cloudfoundry-incubator/etcd/tree/etcd-2.2.0-tls-v1.2-patch-0.
Gotcha. Ok so in the meantime I've sort of hard forked this repo & blobs (not sure how to do this better with bosh) so I can start new etcd cluster's life with v2.3.8 at https://github.com/dingotiles/etcd2-boshrelease/releases/tag/v95.1
I'll get the tls1.2 into it soon; perhaps move the building of etcd into bosh package.
Could we please upgrade to v2.3.X (2.3.7)?
My motivating reason is that etcd core team changed the auth API between minor versions; and also in testing I've observed that a restricted user could modify /v2/key paths outside of their authorized role. This issue didn't appear in v2.3.7 testing; but did appear in v2.2.5 testing.
Sample of different API for etcd v2.2 vs v2.3:
And there is no one golang etcd client that can support both.