This repository was archived by the owner on Jun 23, 2022. It is now read-only.
cmd/kube-client-agent: add mount sub command to consume cert secrets #30
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
OWNERS: init
Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
*: add OpenShift Dockerfiles
Currently the certagent accepts --rootca and --addr, almost all k8s clients usually use the kubeconfig file for creating requests to the k8s api. This also allows the cert agent to create requests with authentication.
CHERRYPICK: "certagent: use kubeconfig to create client for k8s api"
Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
Dockerfile: add rhel images
This PR add support for a new profile EtcdMetric which signs CSR requests with a seperate chain of trust provided by the `--metric-cacrt` and `--metric-cakey` flags. Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
cherry-pick: *: add support for metrics signer
Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
cherry-pick: pkg/certagent: wait forever for CSR request to reply
The previous cert used to test signing metrics certs expired on Apr 19 :( ``` openssl genrsa -out myCA.key 2048 openssl req -x509 -new -nodes -key myCA.key -sha256 -days 3650 -out myCA.pem You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [XX]:US State or Province Name (full name) []:CA Locality Name (eg, city) [Default City]: Organization Name (eg, company) [Default Company Ltd]:fake-metrics-ca Organizational Unit Name (eg, section) []:fake-metrics-ca Common Name (eg, your name or your server's hostname) []: Email Address []: ``` The new one is valid for 10 years.
Currently the etcd-signer-server does not support serving TLS traffic based on SNI. Therefore, since openshift's kube-apiserver serves traffic on api.$cluster_domain and api-int.$cluster_domain [1] and because during bootstrapping when etcd-signer-server is mimic-ing the kube-apiserver to sign the etcd clients certificates it can only serve traffic on single domain, external clients trying to connect to `:6443` from api.$cluster_domain see errors like, ```console time="2019-04-24T13:25:11-07:00" level=debug msg="Still waiting for the Kubernetes API: Get https://api.adahiya-0.tt.testing:6443/version?timeout=32s: x509: certificate is valid for api-int.adahiya-0.tt.testing, not api.adahiya-0.tt.testing" ``` as the etcd-signer-server is using certs for `api-int.$cluster_domain` as internal clients ie etcd agent is contacting it on that domain, the external clients ie the installer hits the etcd-signer on `api.$cluster_domain` Allowing etcd-signer-server to accept multiple certs and serve TLS based on SNI allows it to correctly mimic the kube-apiserver's capability. [1]: openshift/installer#1633
cherry-pick: etcd-signer-server: allow server to serve TLS based on SNI
Since the kube-etcd-signer-server mimics the kube-apiserver's CSR apis to sign certs for etcd, it is usually run on the same port as the kube-apiserver. In those cases serving health checks becomes important as kube-apiserver is usually behind the load-balancers with health checks. Adds `/readyz` health check to the secure server. also adds a flag to serve the same health check on an insecure transport as some cloud only support http health checks.
cherry-pick *: add secure and insecure health checks
Avoid issues like [1]: WARNING: 2018/05/29 11:17:10 Failed to dial 127.0.0.1:2379: connection error: desc = "transport: authentication handshake failed: remote error: tls: bad certificate"; please retry. In the discussion there, the issue seems to be that etcd 3.2 started requiring the client usage for the server cert, which is (for some reason) used when connecting to the gRPC gateway [2,3]. [1]: etcd-io/etcd#9785 (comment) [2]: etcd-io/etcd#9785 (comment) [3]: https://github.com/etcd-io/etcd/blob/v3.3.10/Documentation/dev-guide/api_grpc_gateway.md
Signed-off-by: Sam Batschelet <sbatsche@redhat.com>
This reverts commit 7732233.
alaypatel07
force-pushed
the
mount-secrets
branch
from
632742c to
aace009
Compare
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a
mountsubcommand to kube-client-agent.It will be used by the etcd static pod (managed by ceo) to mount certs generated by cluster-etcd-operator on disk.