Using Replicated Console Certs in Kubernetes Workloads


#1

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


[email protected]:/$ ls /etc/ssl/certs
tls.crt  tls.key


[email protected]:/$ cat /etc/ssl/certs/tls.crt 
-----BEGIN CERTIFICATE-----
MIIDmTCCAoGgAwIBAgIBCDANBgkqhkiG9w0BAQsFADA5MQwwCgYDVQQGEwNVU0Ex
...
-----END CERTIFICATE-----


[email protected]:/$ 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

Let user upload a file to a container's volume through the Management Console?