ingress-nginx-helm/pkg/apis/ingress/sslcert.go

92 lines
2.7 KiB
Go
Raw Normal View History

2016-11-16 18:24:26 +00:00
/*
Copyright 2016 The Kubernetes Authors.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/
package ingress
import (
"crypto/x509"
Add a certificate info metric (#8253) When the ingress controller loads certificates (new ones or following a secret update), it performs a series of check to ensure its validity. In our systems, we detected a case where, when the secret object is compromised, for example when the certificate does not match the secret key, different pods of the ingress controller are serving a different version of the certificate. This behaviour is due to the cache mechanism of the ingress controller, keeping the last known certificate in case of corruption. When this happens, old ingress-controller pods will keep serving the old one, while new pods, by failing to load the corrupted certificates, would use the default certificate, causing invalid certificates for its clients. This generates a random error on the client side, depending on the actual pod instance it reaches. In order to allow detecting occurences of those situations, add a metric to expose, for all ingress controlller pods, detailed informations of the currently loaded certificate. This will, for example, allow setting an alert when there is a certificate discrepency across all ingress controller pods using a query similar to `sum(nginx_ingress_controller_ssl_certificate_info{host="name.tld"})by(serial_number)` This also allows to catch other exceptions loading certificates (failing to load the certificate from the k8s API, ... Co-authored-by: Daniel Ricart <danielricart@users.noreply.github.com> Co-authored-by: Daniel Ricart <danielricart@users.noreply.github.com>
2022-02-24 15:08:32 +00:00
"fmt"
"time"
2017-04-01 14:39:42 +00:00
"k8s.io/apimachinery/pkg/runtime/schema"
2016-11-16 18:24:26 +00:00
)
// SSLCert describes a SSL certificate to be used in a server
type SSLCert struct {
2019-08-13 21:14:55 +00:00
Name string `json:"name"`
Namespace string `json:"namespace"`
Certificate *x509.Certificate `json:"-"`
2019-09-13 12:22:24 +00:00
CACertificate []*x509.Certificate `json:"-"`
2016-11-16 18:24:26 +00:00
// CAFileName contains the path to the file with the root certificate
CAFileName string `json:"caFileName"`
2019-08-13 21:14:55 +00:00
// CASHA contains the sha1 of the ca file.
// This is used to detect changes in the secret that contains certificates
CASHA string `json:"caSha"`
// CRLFileName contains the path to the file with the Certificate Revocation List
CRLFileName string `json:"crlFileName"`
// CRLSHA contains the sha1 of the pem file.
CRLSHA string `json:"crlSha"`
2016-11-16 18:24:26 +00:00
// PemFileName contains the path to the file with the certificate and key concatenated
PemFileName string `json:"pemFileName"`
2019-08-13 21:14:55 +00:00
2016-11-16 18:24:26 +00:00
// PemSHA contains the sha1 of the pem file.
2019-08-13 21:14:55 +00:00
// This is used to detect changes in the secret that contains certificates
2016-11-16 18:24:26 +00:00
PemSHA string `json:"pemSha"`
2019-08-13 21:14:55 +00:00
2016-11-16 18:24:26 +00:00
// CN contains all the common names defined in the SSL certificate
CN []string `json:"cn"`
2019-08-13 21:14:55 +00:00
// ExpiresTime contains the expiration of this SSL certificate in timestamp format
ExpireTime time.Time `json:"expires"`
2019-08-13 21:14:55 +00:00
// Pem encoded certificate and key concatenated
PemCertKey string `json:"pemCertKey,omitempty"`
// UID unique identifier of the Kubernetes Secret
UID string `json:"uid"`
2016-11-16 18:24:26 +00:00
}
// GetObjectKind implements the ObjectKind interface as a noop
func (s *SSLCert) GetObjectKind() schema.ObjectKind {
2017-04-01 14:39:42 +00:00
return schema.EmptyObjectKind
}
2018-07-07 17:46:18 +00:00
Add a certificate info metric (#8253) When the ingress controller loads certificates (new ones or following a secret update), it performs a series of check to ensure its validity. In our systems, we detected a case where, when the secret object is compromised, for example when the certificate does not match the secret key, different pods of the ingress controller are serving a different version of the certificate. This behaviour is due to the cache mechanism of the ingress controller, keeping the last known certificate in case of corruption. When this happens, old ingress-controller pods will keep serving the old one, while new pods, by failing to load the corrupted certificates, would use the default certificate, causing invalid certificates for its clients. This generates a random error on the client side, depending on the actual pod instance it reaches. In order to allow detecting occurences of those situations, add a metric to expose, for all ingress controlller pods, detailed informations of the currently loaded certificate. This will, for example, allow setting an alert when there is a certificate discrepency across all ingress controller pods using a query similar to `sum(nginx_ingress_controller_ssl_certificate_info{host="name.tld"})by(serial_number)` This also allows to catch other exceptions loading certificates (failing to load the certificate from the k8s API, ... Co-authored-by: Daniel Ricart <danielricart@users.noreply.github.com> Co-authored-by: Daniel Ricart <danielricart@users.noreply.github.com>
2022-02-24 15:08:32 +00:00
// Identifier returns a the couple issuer / serial number if they both exist, an empty string otherwise
func (s *SSLCert) Identifier() string {
Add a certificate info metric (#8253) When the ingress controller loads certificates (new ones or following a secret update), it performs a series of check to ensure its validity. In our systems, we detected a case where, when the secret object is compromised, for example when the certificate does not match the secret key, different pods of the ingress controller are serving a different version of the certificate. This behaviour is due to the cache mechanism of the ingress controller, keeping the last known certificate in case of corruption. When this happens, old ingress-controller pods will keep serving the old one, while new pods, by failing to load the corrupted certificates, would use the default certificate, causing invalid certificates for its clients. This generates a random error on the client side, depending on the actual pod instance it reaches. In order to allow detecting occurences of those situations, add a metric to expose, for all ingress controlller pods, detailed informations of the currently loaded certificate. This will, for example, allow setting an alert when there is a certificate discrepency across all ingress controller pods using a query similar to `sum(nginx_ingress_controller_ssl_certificate_info{host="name.tld"})by(serial_number)` This also allows to catch other exceptions loading certificates (failing to load the certificate from the k8s API, ... Co-authored-by: Daniel Ricart <danielricart@users.noreply.github.com> Co-authored-by: Daniel Ricart <danielricart@users.noreply.github.com>
2022-02-24 15:08:32 +00:00
if s.Certificate != nil {
if s.Certificate.SerialNumber != nil {
return fmt.Sprintf("%s-%s", s.Certificate.Issuer.SerialNumber, s.Certificate.SerialNumber.String())
}
}
return ""
}
2018-07-07 17:46:18 +00:00
// HashInclude defines if a field should be used or not to calculate the hash
func (s *SSLCert) HashInclude(field string, _ interface{}) (bool, error) {
switch field {
case "PemSHA", "CASHA", "ExpireTime":
return true, nil
default:
return false, nil
}
2018-07-07 17:46:18 +00:00
}