Overview
Red Hat OpenShift uses certificates to encrypt the communication with the Web Console as well as applications exposed as Routes. Without any further customization the install process will create self-signed certificates. While these work they usually trigger severe security warnings about unknown certificates in Web Browsers when accessing either the Web Console or any other application that is exposed via HTTPS.
Therefore for any Red Hat OpenShift cluster, it is suggested to use proper certificates to encrypt the routes and API endpoints. For many years, this required paying for the generation of those certificates and managing them across an organization. Today, thanks to Let’s Encrypt, this process can be automated and performed for free.
Luckily in OpenShift 4, it is reasonably straightforward to apply certificates after the installation has completed.
This blog walks through using Let’s Encrypt to provision certificates for your cluster in AWS. You will need to know the API endpoint URL and the Wildcard Domain for your ingress controller(s).
Installing acme.sh
If you already have certificates for your domains, you may skip this step and go straight to Installing Certificates for the Router.
In order to request Let’s Encrypt certificates we will use the acme.sh client. This client makes it very easy to request and update certificates.
- Clone the acme.sh GitHub repository.
- cd acme.sh
- Update the file $HOME/acme.sh/dnsapi/dns_aws.sh with your AWS access credentials. This is necessary because you are requesting a certificate for a wildcard domain and Let’s Encrypt needs a way to validate that you are the owner of the wildcard domain.
- Open the file in your favorite text editor and then add your AWS credentials. You will also need to remove the comment (#) before these two lines. The top of the file should look like this:
cd $HOME
git clone https://github.com/neilpang/acme.sh
#!/usr/bin/env sh
#
AWS_ACCESS_KEY_ID="YOUR ACCESS KEY"
#
AWS_SECRET_ACCESS_KEY="YOUR SECRET ACCESS KEY"
#This is the Amazon Route53 api wrapper for acme.sh
[...]
Requesting Certificates
- Make sure that you are connected to your Red Hat OpenShift Cluster. You can either do these steps from a bastion host that you installed Red Hat OpenShift from or you can log into the cluster as a user that has cluster administrator permissions. Right after the installation this includes the system:admin and kubeadmin users.
- To make things a bit easier, set two environment variables. The first variable should point to your API Endpoint. Use the oc CLI to find the API Endpoint URL.
- oc whoami --show-server
- Now set the variable LE_API to the fully qualified domain name:
- Set the second variable LE_WILDCARD to your Wildcard Domain for example:
- Run the acme.sh script. This will request one certificate which will be valid for both the API Server hostname and the default wildcard domain.
- It is usually a good idea to move the certificates from the acme.sh default path to a well known directory. So use the --install-cert option of the acme.sh script to copy the certificates to $HOME/certificates.
Sample Output
https://cluster-e954-api.e954.ocp4.opentlc.com:6443
export LE_API=$(oc whoami --show-server | cut -f 2 -d ':' | cut -f 3 -d '/' | sed 's/-api././')
export LE_WILDCARD=$(oc get ingresscontroller default -n openshift-ingress-operator -o jsonpath='{.status.domain}')
${HOME}/acme.sh/acme.sh --issue -d ${LE_API} -d *.${LE_WILDCARD} --dns dns_aws
export CERTDIR=$HOME/certificates
mkdir -p ${CERTDIR}
${HOME}/acme.sh/acme.sh --install-cert -d ${LE_API} -d *.${LE_WILDCARD} --cert-file ${CERTDIR}/cert.pem --key-file ${CERTDIR}/key.pem --fullchain-file ${CERTDIR}/fullchain.pem --ca-file ${CERTDIR}/ca.cer
Installing Certificates for the Default Ingress Controllers
The following instructions work for OpenShift 4.6 and higher.
The ingress controller expects the certificates in a Secret. This secret needs to be created in the project openshift-ingress.
- Use the following command to create the secret - and if you have existing certificates, make sure to provide the path to your certificates instead.
- Now update the Custom Resource for your ingress controller. The default custom resource is of type IngressController, is named default and is located in the openshift-ingress-operator project. Note that this project is different from where you created the secret earlier.
- This is all you need to do. After you update the IngressController object the OpenShift ingress operator notices that the custom resource has changed and therefore re-deploys the router.
- Use the following command to create the secret - and if you have existing certificates, make sure to provide the path to your certificates instead.
- Now update the Custom Resource for your API server. The custom resource is of type APIServer and is named cluster.
- This is all you need to do. After you update the APIServer object the OpenShift API operator notices that the custom resource has changed and therefore re-deploys the API Servers. Note that this will take about 5 minutes per APIServer - which means about 15 minutes for a regular high availability deployment of OpenShift.
oc create secret tls router-certs --cert=${CERTDIR}/fullchain.pem --key=${CERTDIR}/key.pem -n openshift-ingress
oc patch ingresscontroller default -n openshift-ingress-operator --type=merge --patch='{"spec": { "defaultCertificate": { "name": "router-certs" }}}'
You now have proper certificates on the router - and this includes custom applications exposed using the default route, the Web Console for your OpenShift Cluster and various other services like the Monitoring stack. .
Installing Certificates for the API Endpoint
The API Server also expects the certificates in a Secret. This secret needs to be created in the project openshift-config.
oc create secret tls api-certs --cert=${CERTDIR}/fullchain.pem --key=${CERTDIR}/key.pem -n openshift-config
oc patch apiserver cluster --type merge --patch="{\"spec\": {\"servingCerts\": {\"namedCertificates\": [ { \"names\": [ \"$LE_API\" ], \"servingCertificate\": {\"name\": \"api-certs\" }}]}}}"
You now have proper certificates on the API Endpoint. Note that depending on the age of your operating system you may still see an insecure connection error when using the `oc login` command - newer operating systems already trust the Let’s Encrypt certificate authority.
저자 소개
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.