kops: kops creates two CA certificates which breaks certificate-controller from signing certs.
What kops version are you running? use kops version
master
What Kubernetes version are you running? use kubectl version
1.8.3
What cloud provider are you using? AWS
What commands did you execute (Please provide cluster manifest kops get --name my.example.com, if available) and what happened after commands executed?
kubectl get csr csr_request
What you expected to happen: I excpected to get a certificat in .status.certificate
How can we to reproduce it (as minimally and precisely as possible): By following the directions here https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/
Anything else do we need to know:
I have tracked this down to kops creating two certificates in /srv/kuberentes/ca.crt it also creates two certificate and private key files in the s3 bucket at locations /pki/issued/ca and /pki/private/ca. I have been able to get kubernetes to sign certificates by quickly deleting one of the files from the bucket while creating a new cluster so that they only get one certificate.
Here is an error from controller-manager
I1116 16:09:47.033806 5 controller_utils.go:1019] Waiting for caches to sync for persistent volume controller
I1116 16:09:47.284974 5 controllermanager.go:488] Started "endpoint"
I1116 16:09:47.284997 5 controllermanager.go:478] Starting "csrsigning"
I1116 16:09:47.285063 5 endpoints_controller.go:153] Starting endpoint controller
I1116 16:09:47.285077 5 controller_utils.go:1019] Waiting for caches to sync for endpoint controller
E1116 16:09:47.425756 5 certificates.go:49] Failed to start certificate controller: error parsing CA cert file "/srv/kubernetes/ca.crt": {"code":1003,"message":"the PEM file should contain only one object"}
W1116 16:09:47.425778 5 controllermanager.go:485] Skipping "csrsigning"
I1116 16:09:47.425786 5 controllermanager.go:478] Starting "service"
I1116 16:09:47.683734 5 controllermanager.go:488] Started "service"
cat /srv/kubernetes/ca.crt
-----BEGIN CERTIFICATE-----
MIIC0zCCAbugAwIBAgIMFPecowJWaxgTWcRdMA0GCSqGSIb3DQEBCwUAMBUxEzAR
BgNVBAMTCmt1YmVybmV0ZXMwHhcNMTcxMTE0MTYwNzAzWhcNMjcxMTE0MTYwNzAz
WjAVMRMwEQYDVQQDEwprdWJlcm5ldGVzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEAyRr0AKsEOqYCI6gHg0kgcAauus9nA+Z/pn4bVL+i21/L8q7EjxVf
yX3v3lz2627s2GBDquVoT2LG7gicKIOTUNMmMop1vMasdZ16xUauN0nB9Z9E60Oy
2g+L9xFqDXyUJ+S4A8EbY19DV5G5M0rb/XL2pzSTe+uOOEjEf2e2kQSjOnPugZpo
MLSLkHeyFTVYlCrF85HxsdAAlXglKJ3ZDT3wP1qZ5a/02TutrHhgBRoWjmWqpTr8
MPduBFAG/6b+56+XuXior7TKhT1Lsulw3wCwKrXMIXViRqdV96w6yuiolgRx1+Y6
PyhXANF8sb/t0GLgPVECpyPcxXDBozFFxQIDAQABoyMwITAOBgNVHQ8BAf8EBAMC
AQYwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQsFAAOCAQEASYzBLpHuMlxl
E5i3feVYZnlxyHI1mdY+pzRUEp43V7gA7amYRlmNwHfGbCv0faNZc9TXlKf2QDjx
GnQ+aPeNDbbjmviRMDX2/1JnUkeZ1Um6ZZ/CN63p9EBh+RcUa9zhqhIzTbqspNW8
SzlgnIeSbOEJ5iTCawm3x9EkGPNVIKOeqdTSPzsy0QRb9odO2RcyW1gLeiVImwPt
cH+DfyENZGQlgb8Ez23zCiXiWVthervoOaFsXiA3PK6D6mQFZphzdKJi2XmrVbuw
r6GfMmcArIzzvAnu4gXYPLO94ylYfY/gecxsKWpXx1Gw+cCVtOEv0dhluRkpi26c
lW4r0bX7EA==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIC2DCCAcCgAwIBAgIRAPDTW6ueFfuNmGemU9bsK1QwDQYJKoZIhvcNAQELBQAw
FTETMBEGA1UEAxMKa3ViZXJuZXRlczAeFw0xNzExMTQxNjA3MDNaFw0yNzExMTQx
NjA3MDNaMBUxEzARBgNVBAMTCmt1YmVybmV0ZXMwggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDJGvQAqwQ6pgIjqAeDSSBwBq66z2cD5n+mfhtUv6LbX8vy
rsSPFV/Jfe/eXPbrbuzYYEOq5WhPYsbuCJwog5NQ0yYyinW8xqx1nXrFRq43ScH1
n0TrQ7LaD4v3EWoNfJQn5LgDwRtjX0NXkbkzStv9cvanNJN76444SMR/Z7aRBKM6
c+6BmmgwtIuQd7IVNViUKsXzkfGx0ACVeCUondkNPfA/Wpnlr/TZO62seGAFGhaO
ZaqlOvww924EUAb/pv7nr5e5eKivtMqFPUuy6XDfALAqtcwhdWJGp1X3rDrK6KiW
BHHX5jo/KFcA0Xyxv+3QYuA9UQKnI9zFcMGjMUXFAgMBAAGjIzAhMA4GA1UdDwEB
/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQAGhKKc
DpE7L1Qu/SZIdctVW4EfVJ49uxUzklDOm13yrAKLForlcwVHnGhXNDfRo//clovM
BGKhZST7O9/L3I1m+mBgPOqBJ4NW4oyr53IOZun6cv6tcIYSWV9xoOHNFX8Nw9ty
FHsXDSpNu9ogGM06XcKnVp9sfcH8TywSzPTPM2f8UpXmyhIOx5yp9PjZh038u528
+EInpZ28H1wwffz5+vAfuv85AZ9LVeZR2s2uJThE0TlX4qyCwH0PlJzXbN9YyO7/
NrR5qdbughkMlY6BweXobVQ6qwvO4JmZIpsRJmzDNwSuc85kT42fHrAvfcL3O4EM
T/02GeBfmKqMDPQG
-----END CERTIFICATE-----

About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 1
- Comments: 18 (10 by maintainers)
Commits related to this issue
- Avoid generating a CA keypair on-demand Instead we must explicitly create it; this avoids races where we are reading the private key and creating CA certs. Issue #3875 — committed to justinsb/kops by justinsb 7 years ago
- Avoid generating a CA keypair on-demand Instead we must explicitly create it; this avoids races where we are reading the private key and creating CA certs. Issue #3875 — committed to justinsb/kops by justinsb 7 years ago
- Avoid generating a CA keypair on-demand Instead we must explicitly create it; this avoids races where we are reading the private key and creating CA certs. Issue #3875 — committed to justinsb/kops by justinsb 7 years ago
Any chance we can get a quick confirmation on the work around for those hitting this issue? From what I can tell, if you already have a cluster up you need to delete either first or second certificate, and the matching key (first or second) from the following locations leaving only one certificate and key in each.
s3://${KOPS_STATE_STORE}/${CLUSTER}/pki/issued/ca s3://${KOPS_STATE_STORE}/${CLUSTER}/pki/private/ca
Then perform a rolling-update.