Cert-manager: Minimal deployment without Helm

Created on 14 Feb 2018 · 6Comments · Source: jetstack/cert-manager

Documentation for deployment without Helm as well as the minimal requirements.

/kind feature

In the master branch is a docs/deploy folder and a docs/examples folder. I know the deploy folder is auto generated from the Helm chart. The examples folder includes some duplicate functionality (but different files) as well as examples for creating actual issuers and certificates.

If I want to run a cert-manager per namespace, no ingress-shim, no ClusterIssuer, what yaml files are required for k8s v1.8.5.

From the examples folder do I really only need crd.yaml and cert-manager.yaml as my base and then write my own custom Certificate and Issuer using acme-issuer.yaml and acme-cert.yaml as examples?

Or do I need things that are in the deploy/rbac/rbac.yaml and deploy/rbac/serviceaccount.yaml?

kinfeature

Source

mbinette

Most helpful comment

I used the deploy/manifests files to create my own set of yaml files that were clean without any mention of Helm.

namespace.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: cert-manager

crd.yaml

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: certificates.certmanager.k8s.io
  labels:
    app: cert-manager
spec:
  group: certmanager.k8s.io
  version: v1alpha1
  names:
    kind: Certificate
    plural: certificates
  scope: Namespaced
---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: issuers.certmanager.k8s.io
  labels:
    app: cert-manager
spec:
  group: certmanager.k8s.io
  version: v1alpha1
  names:
    kind: Issuer
    plural: issuers
  scope: Namespaced
---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: clusterissuers.certmanager.k8s.io
  labels:
    app: cert-manager
spec:
  group: certmanager.k8s.io
  version: v1alpha1
  names:
    kind: ClusterIssuer
    plural: clusterissuers
  scope: Cluster

serviceaccount.yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: cert-manager
  namespace: cert-manager
  labels:
    app: cert-manager

rbac.yaml

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: cert-manager
  labels:
    app: cert-manager
rules:
  - apiGroups: ["certmanager.k8s.io"]
    resources: ["certificates", "issuers", "clusterissuers"]
    verbs: ["*"]
  - apiGroups: [""]
    resources: ["secrets", "events", "endpoints", "services", "pods"]
    verbs: ["*"]
  - apiGroups: ["extensions"]
    resources: ["ingresses"]
    verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: cert-manager
  labels:
    app: cert-manager
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cert-manager
subjects:
  - name: cert-manager
    namespace: cert-manager
    kind: ServiceAccount

cert-manager.yaml

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: cert-manager
  namespace: cert-manager
  labels:
    app: cert-manager
spec:
  replicas: 1
  strategy:
    type: Recreate
  template:
    metadata:
      labels:
        app: cert-manager
    spec:
      serviceAccountName: cert-manager
      containers:
        - name: cert-manager
          image: "quay.io/jetstack/cert-manager-controller:v0.2.3"
          args: ["--cluster-resource-namespace","cert-manager"]
          imagePullPolicy: IfNotPresent
          resources:
            requests:
              cpu: 10m
              memory: 32Mi
#        - name: ingress-shim
#          image: "quay.io/jetstack/cert-manager-ingress-shim:v0.2.3"
#          imagePullPolicy: IfNotPresent
#          resources:
#            requests:
#              cpu: 10m
#              memory: 32Mi

issuer.yaml

apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-staging.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-prod
    dns01:
      providers:
      - name: prod-dns
        clouddns:
          serviceAccountSecretRef:
            name: letsencrypt-credentials
            key: credentials.json
          project: your-gcp-project

cert.yaml

apiVersion: certmanager.k8s.io/v1alpha1
kind: Certificate
metadata:
  name: your-app-cert
  namespace: kube-system
spec:
  secretName: your-app-tls
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  commonName: your-app.com
  dnsNames:
  - dev.your-app.com
  - qa.your-app.com
  - www.your-app.com
  acme:
    config:
    - dns01:
        provider: prod-dns
      domains:
      - your-app.com
      - dev.your-app.com
      - qa.your-app.com
      - www.your-app.com

mbinette on 17 Dec 2018

❤12 👍10

All 6 comments

RBAC and Service Accounts are how you control users and applications can do. Without them, every user and container in your cluster has 'root' privileges. If security isn't a consideration in your cluster, then you don't need to create them, and you can just use the default Service Account in each namespace.

https://kubernetes.io/docs/admin/authorization/rbac/
https://kubernetes.io/docs/admin/authentication/#service-account-tokens

whereisaaron on 15 Feb 2018

Thanks. I read up on all of that. It was the first time I saw a k8s service-account defined and couldn't get it out of my head that this wasn't the same as the GCP Service Accounts used for my other deployments.

In the rbac.yaml there is a ClusterRoleBinding with:

subjects:
  -name: cert-manager
   namespace: "default"
   kind: ServiceAccount

All the examples I say wouldn't have the "namespace" defined here. I will have 3 namespaces, all with their own cert-manager, Issuer, and Certificate. Do I need a separate ClusterRoleBinding for each or should I change this to RoleBinding or can I simply remove the "namespace" entry and have it work across namespaces?

mbinette on 15 Feb 2018

Probably you should mess with RBAC until you get the hang of it, there is some material around:
https://coreos.com/blog/hands-on-with-rbac-in-kubernetes-1.8

Once you do, you might reconsider if you really need to run cert-manager in each namespace. It is probably more secure to run one cert-manager in a fourth namespace, with RBAC access to create Certificates (for ingress-shim) and Secrets in the three namespaces. Then users can create namespaced Issuers and Certificates and be well separated.