Using Replicated Console Certs in Kubernetes Workloads

Often, you’ll want to give your Kubernetes+Replicated application access to the Replicated SSL certificates. This example includes an example for storing the replicated SSL data in a secret so it can be consumed by other workloads like reverse proxies and Ingress resources.

---
# kind: replicated
replicated_api_version: 2.18.0
name: Replicated+Kubernetes TLS Demo


host_requirements:
  replicated_version: ">=2.18.0"
properties:
  console_title: Admin Console
---
# kind: scheduler-kubernetes
apiVersion: v1
kind: Secret
metadata:
  name: www-tls
# A generic v1/Secret that stores the Replicated Admin Console certificates
type: kubernetes.io/tls
data:
  tls.crt: '{{repl ConsoleSetting "tls.cert.data" | Base64Encode }}'
  tls.key: '{{repl ConsoleSetting "tls.key.data" | Base64Encode }}'
---
# kind: scheduler-kubernetes
apiVersion: apps/v1
kind: Deployment
metadata:
  name: www
  labels:
    tier: www
# An example nginx deployment that consumes the secret
spec:
  selector:
    matchLabels:
      tier: www
  replicas: 3
  template:
    metadata:
      labels:
        tier: www
    spec: 
      volumes:
      - name: tls
        secret:
          secretName: www-tls
      containers:
      - name: www-test-container
        image: nginx:latest
        volumeMounts:
        - name: tls
          readOnly: true
          mountPath: "/etc/ssl/certs/"

Note that the above nginx workload isn’t configured to use the certificates yet, but we can exec into the container to ensure they’ve been mounted properly:

$ kubectl -n replicated-0590db2a890f4b434360e30c1348673d exec -it www-56d797474b-rmq7b bash


root@www-56d797474b-rmq7b:/$ ls /etc/ssl/certs
tls.crt  tls.key


root@www-56d797474b-rmq7b:/$ cat /etc/ssl/certs/tls.crt 
-----BEGIN CERTIFICATE-----
MIIDmTCCAoGgAwIBAgIBCDANBgkqhkiG9w0BAQsFADA5MQwwCgYDVQQGEwNVU0Ex
...
-----END CERTIFICATE-----


root@www-56d797474b-rmq7b:/$ cat /etc/ssl/certs/tls.key 
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAypBqm78lIukqi/RoKNWxxqNrGmhJdpesBuW8d38p2rdQaMYz
...
-----END RSA PRIVATE KEY-----

Usage with Contour

For contour, you’ll want to create a secret and Ingress object to forward to your services. Note that contour requires a dns name that matches the cert CN/SAN, IP addresses will not work.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name:  myapp-ingress
spec:
  tls:
    - hosts:
      - '{{repl ConsoleSetting "tls.hostname"}}'
        secretName: myapp-tls
  rules:
    - http:
        paths:
          - path: /*
            backend:
              serviceName: myapp-ui
              servicePort: 3000
          - path: /api/*
            backend:
              serviceName: myapp-api
              servicePort: 3000
          - path: /graphql
            backend:
              serviceName: myapp-api
              servicePort: 3000

    - host: '{{repl ConsoleSetting "tls.hostname"}}'
      http:
        paths:
          - path: /*
            backend:
              serviceName: myapp-ui
              servicePort: 3000
          - path: /api/*
            backend:
              serviceName: myapp-api
              servicePort: 3000
          - path: /graphql
            backend:
              serviceName: myapp-api
              servicePort: 3000
---
# kind: scheduler-kubernetes
apiVersion: v1
data:
  tls.key: '{{repl ConsoleSetting "tls.key.data" | Base64Encode }}'
  tls.crt: '{{repl ConsoleSetting "tls.cert.data" | Base64Encode }}'
kind: Secret
metadata:
  name: myapp-tls
  namespace: default
type: kubernetes.io/tls

Hey dex, Is the ConsoleSetting function still works? I get an error when trying to use it.

function "ConsoleSetting" not defined

This post was for an older version of Replicated afaik. If you’re using kots, you can use ConfigOption. See also the docs for an example

Okay, but is it possible to use the admin console certificates with ConfigOption ?

Not sure if I fully understand your question, but I think you’re referring to the kostadm-tls secret: