-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Implement TLS by default for Minikube + Helm installer #476
Changes from all commits
a28594c
33cc5a6
3c721e6
1587bd4
b1b05b5
bcd927a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,11 @@ | ||
# CA key pair generation job container | ||
FROM alpine | ||
|
||
RUN apk add --no-cache openssl curl && \ | ||
cd /usr/local/bin && \ | ||
curl -s -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl && \ | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. seems strange to join the |
||
chmod +x kubectl && \ | ||
apk del curl | ||
|
||
COPY entrypoint.sh /entrypoint.sh | ||
ENTRYPOINT ["/entrypoint.sh"] |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,3 @@ | ||
#!/bin/sh | ||
|
||
docker build -t quay.io/eclipse/che-cert-manager-ca-cert-generator . |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,36 @@ | ||
#!/bin/sh | ||
|
||
CA_KEY_FILE='ca.key' | ||
CA_CERT_FILE='ca.crt' | ||
|
||
# Generate private key for root CA | ||
# Options: | ||
# -out : name of file to write generated key to | ||
# 4096 : number of bits in the key | ||
openssl genrsa -out $CA_KEY_FILE 4096 | ||
|
||
# Generate CA certificate and sign it with previously generated key. | ||
# Options: | ||
# -batch : script (non-interactive) mode | ||
# -new : creates new sertificate request | ||
# -x509 : produces self signed sertificate instead of certificate request | ||
# -deys : number of days this certificate will be valid for | ||
# -key : private key to use to sign this certificate | ||
# -subj : subject name. Should contain at least distinguished (common) name (CN). Format: /type0=value0/type1=value1 | ||
# -addext : adds extension to certificate (inline version of -reqexts with -config) | ||
# -outform : format of the certificate container | ||
# -out : name of file to write generated certificate to | ||
CA_CN='eclipse-che-local-CA' | ||
openssl req -batch -new -x509 -days 730 -key $CA_KEY_FILE \ | ||
-subj "/CN=${CA_CN}" \ | ||
-addext keyUsage=keyCertSign,cRLSign,digitalSignature \ | ||
-outform PEM -out $CA_CERT_FILE | ||
# Do not include CA:TRUE as it is already included into default config file | ||
#-addext basicConstraints=critical,CA:TRUE | ||
|
||
# Create CA root certificate secret | ||
|
||
CERT_MANAGER_NAMESPACE='cert-manager' | ||
CERT_MANAGER_CA_SECRET_NAME='ca' | ||
|
||
kubectl create secret tls $CERT_MANAGER_CA_SECRET_NAME --key=$CA_KEY_FILE --cert=$CA_CERT_FILE --namespace $CERT_MANAGER_NAMESPACE | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So.. .this container is just kubectl + a cert? Instead of new container, could we instead just add this cert into https://github.com/che-dockerfiles/che-sidecar-kubernetes-tooling and keep the proliferation of containers (and therefore things that need to be productized) to a minimum? CRW 1.2 was 8 containers. 2.0 was 20. 2.1 is up to 23 and counting. Can we try to reuse our existing tiny containers (and their existing builds/infra/sync jobs/productization pipeline) and just add a new kb of new files into them?? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @nickboldt yes, this container indeed contains kubectl and openssl only, but we cannot reuse Kubernetes tolling sidecar for the Cert Manager job. First, they have different purposes: the job completes its tasks and exists, whereas Kubernetes tooling sidecar is designed to be run as a part of a workspace. Second, they have different aims: generate certificate and serve queries to Kubernetes respectively. Third, chectl (and Che installation process) should not depend on a Che sidecar. That's logically wrong and error prone: if something is changed in Kubernetes Che plugin it could break Che installation. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. sigh OK, I was hoping for reuse and less proliferation of single-use containers. Your logic is sound, but still makes me sad. :( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So when this is on by default, how do you actually switch it off? Do we have something like
--no-tls
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No we don't have
--no-tls
flag, so a user cannot switch it off on Kubernetes-like infrastructures. The same is planned for Openshift soon. Although, we are going to keep the--tls
flag for backward compatibility only.Turning it off not only dangerous from user security point of view, but also some components might not work properly without TLS (as you probably know the story about Theia webviews).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so if TLS is on by default and no longer disableable, the flag would effectively do nothing?
Will you also ensure the fields in custom resource.yaml no longer work, so that it's no longer possible to set
tlsSupport: false
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nickboldt yes the flag will do nothing... Please see the thread #476 (comment).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As about
tlsSupport
flag in CRDs... you are right, we have to take a look and prevent breaking stuff with wrong value of the flag.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But I think it should be done when I'll be working on operator part.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK as long as this TODO is captured in a GH issue for that task, then +1. Just don't want to forget this part. :D