Securing OpenShift Ingress and API with cert-manager

Introduction

In this post, we will be Securing OpenShift Ingress and API with cert-manager. We will create Certificates for OpenShift in order to secure your traffic using HTTPS (SSL/TLS) using also Let’s Encrypt. At Octopus, we’ve seen firsthand how important security is in the world of cloud services. Our team’s deep understanding in OpenShift, Kubernetes and open-source technologies ensures that we’re guiding our clients through these kind of security requirements.

Cert-manager relevant objects

We have a separate guide for managing user certificates with cert-manager but in this guide we will concentrate on OpenShift infrastructure certificates.

ClusterIssuer

In cert-manager, a ClusterIssuer helps manage certificate issuance on a cluster-wide scope. Instead of dealing with individual issuers per namespace, a ClusterIssuer allows you to set a single point of certificate management that can serve certificates to applications across different namespaces. This is particularly useful for ensuring consistent certificate policies and simplifying certificate management in larger Kubernetes deployments

In this guide we assume you have a ClusterIssuer name letsencrypt-production and letsencrypt-staging

Certificate Authority (CA)

A CA (Certificate Authority) object is used to represent a Certificate Authority that can issue certificates. In cert-manager you can create one, but in this guide we will be using Let’s Encrypt’s CA to act as out Certificate Authority, enabling cert-manager to issue certificates based on their CA. Cert-manager will help us automate the process using Let’s Encrypt.

Let’s Encrypt

Let’s Encrypt is a widely-used, free certificate authority that provides SSL/TLS certificates for securing web traffic. Its automated processes make obtaining and deploying certificates incredibly easy and efficient. It requires to be connected to the internet and allow access from the internet to the cluster. For air-gapped environment, there are also options for issuing know certificates based on the same protocol Let’s Encrypt is using, the ACME protocol.

Let’s Encrypt uses the ACME protocol (Automatic Certificate Management Environment) to automate the process of renewing SSL/TLS certificates. ACME is the communication protocol that enables a server to request certificates from Let’s Encrypt and prove its control over the domain. Let’s Encrypt acts as the Certificate Authority, while ACME is the protocol facilitating the automated, secure, and seamless issuance and management of certificates between Let’s Encrypt and the servers

Let’s Encrypt works effectively because it automates the process of obtaining and renewing SSL/TLS certificates, removing the historically complex and costly barriers.

Procedure

Secure oauth and console endpoints

Let’s create a certificate called oauth-cert with cert-manager for oauth-openshift service

01_oauth-cert.yaml

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: oauth-cert
  namespace: openshift-authentication
  labels:
    app: cert-manager
spec:
  secretName: ingress-cert
  secretTemplate:
    labels:
      app: cert-manager
  duration: 2160h # 90d
  renewBefore: 360h # 15d
  subject:
    organizations:
      - Octopus K8s Service
  commonName: 'oauth-openshift.apps.example.customers.k8s.co.il'
  privateKey:
    algorithm: RSA
    encoding: PKCS1
    size: 2048
    rotationPolicy: Always
  usages:
    - server auth
    - client auth
  dnsNames:
    - 'oauth-openshift.apps.example.customers.k8s.co.il'
  issuerRef:
    name: letsencrypt-staging
    kind: ClusterIssuer

Now let’s do the same with a certificate called ingress-cert for console-openshift-console service

02_ingress-cert.yaml

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: ingress-cert
  namespace: openshift-ingress
  labels:
    app: cert-manager
spec:
  secretName: ingress-cert
  secretTemplate:
    labels:
      app: cert-manager
  duration: 2160h # 90d
  renewBefore: 360h # 15d
  subject:
    organizations:
      - Octopus K8s Service
  commonName: 'console-openshift-console.apps.example.customers.k8s.co.il'
  privateKey:
    algorithm: RSA
    encoding: PKCS1
    size: 2048
    rotationPolicy: Always
  usages:
    - server auth
    - client auth
  dnsNames:
    - 'console-openshift-console.apps.example.customers.k8s.co.il'
  issuerRef:
    name: letsencrypt-staging
    kind: ClusterIssuer

Once the certificate is set, we can patch the ingresscontroller with the following command:

$ oc patch ingresscontroller default -n openshift-ingress-operator --type=merge --patch='{"spec": { "defaultCertificate": { "name": "ingress-cert" }}}' --insecure-skip-tls-verify

Secure OpenShift API Endpoint

Additionally in OpenShift we can connect to the API endpoint with a tool like oc or other tools, for securing this service with cert-manager and Let’s encrypt we will use the following Certificate called api-cert for api service

03_api-cert.yaml

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-cert
  namespace: openshift-config
  labels:
    app: cert-manager
spec:
  secretName: api-cert
  secretTemplate:
    labels:
      app: cert-manager
  duration: 2160h # 90d
  renewBefore: 360h # 15d
  subject:
    organizations:
      - Octopus K8s Service
  commonName: 'api.example.customers.k8s.co.il'
  privateKey:
    algorithm: RSA
    encoding: PKCS1
    size: 2048
    rotationPolicy: Always
  usages:
    - server auth
    - client auth
  dnsNames:
    - 'api.example.customers.k8s.co.il'
    - 'api-int.example.customers.k8s.co.il'
  issuerRef:
    name: letsencrypt-production
    kind: ClusterIssuer

Now, our api endpoint is also secured and managed via cert-manager.

Summary

Certificates are a must for securing data and preventing unauthorized eavesdropping to organization traffic. In this guide we’ve shown how securing OpenShift Ingress and API with cert-manager is a simple. Following this quick guide you gain better security and privacy across your organization for your Kubernetes traffic. At Octopus we value security especially for these kind of use cases. Feel free to approach us for additional information.