You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 11, 2023. It is now read-only.
Is this an ISSUE or FEATURE REQUEST? (choose one):
ISSUE
What version of acs-engine?:
v0.12.1
Orchestrator and version (e.g. Kubernetes, DC/OS, Swarm)
Kubernetes
What happened:
If I reference the etcd peer certs and keys in apimodel.json (at .properties.certificateProfile.etcdPeerCertificates and .properties.certificateProfile.etcdPeerPrivateKeys) using a KeyVault, the certificate values are not fetched from KeyVault. Instead the path to the secret in KeyVault is passed on to the masters.
This means that the etcd on master doesn't start properly and hence the cluster doesn't work.
It looks like the issue lies somewhere in acs-engine because the parameters file generated after acs-engine generate doesn't have the KeyVault references, instead they are the base64 encoded paths to secret in KeyVault.
What you expected to happen:
Secrets referred via KeyVault should work for etcdPeerCertificates and etcdPeerPrivateKeys as well.
How to reproduce it (as minimally and precisely as possible):
In the attached apimodel.zip, replace the --REDACTED-- and KeyVault paths in certificateProfile section to valid values and try to deploy.
Once master VMs are created check for content of /etc/kubernetes/certs/etcdpeer0.crt or /etc/kubernetes/certs/etcdpeer0.key. It will be the KeyVault path to secret instead of secret's value from KeyVault. Etcd service should be failed and error can be seen in journalctl -xe.
Anything else we need to know:
The text was updated successfully, but these errors were encountered:
Hi @aku105, thank you for reporting. PR #2155 should fix this issue. I am still testing it to make sure it doesn't introduce any unwanted behavior but I will let you know when it is merged.
Is this a request for help?:
Yes
Is this an ISSUE or FEATURE REQUEST? (choose one):
ISSUE
What version of acs-engine?:
v0.12.1
Orchestrator and version (e.g. Kubernetes, DC/OS, Swarm)
Kubernetes
What happened:
If I reference the etcd peer certs and keys in apimodel.json (at
.properties.certificateProfile.etcdPeerCertificates
and.properties.certificateProfile.etcdPeerPrivateKeys
) using a KeyVault, the certificate values are not fetched from KeyVault. Instead the path to the secret in KeyVault is passed on to the masters.This means that the etcd on master doesn't start properly and hence the cluster doesn't work.
It looks like the issue lies somewhere in acs-engine because the parameters file generated after
acs-engine generate
doesn't have the KeyVault references, instead they are the base64 encoded paths to secret in KeyVault.What you expected to happen:
Secrets referred via KeyVault should work for
etcdPeerCertificates
andetcdPeerPrivateKeys
as well.How to reproduce it (as minimally and precisely as possible):
In the attached apimodel.zip, replace the
--REDACTED--
and KeyVault paths in certificateProfile section to valid values and try to deploy.Once master VMs are created check for content of
/etc/kubernetes/certs/etcdpeer0.crt
or/etc/kubernetes/certs/etcdpeer0.key
. It will be the KeyVault path to secret instead of secret's value from KeyVault. Etcd service should be failed and error can be seen injournalctl -xe
.Anything else we need to know:
The text was updated successfully, but these errors were encountered: