okteto / cert-manager-webhook-civo Goto Github PK

View Code? Open in Web Editor NEW

21.0 4.0 7.0 222 KB

A webhook to use CIVO DNS as a DNS issuer for cert-manager.

License: Apache License 2.0

Dockerfile 9.46% Makefile 5.08% Go 58.82% Mustache 26.65%

civo kubernetes okteto letsencrypt cert-manager cert-manager-webhook

cert-manager-webhook-civo's Introduction

Cert-Manager ACME DNS01 Webhook Solver for CIVO DNS

This solver can be used when you want to use cert-manager with CIVO DNS.

Installation

cert-manager

Follow the instructions using the cert-manager documentation to install it within your cluster.

cert-manager-webhook-civo

helm install cert-manager-webhook-civo oci://ghcr.io/okteto/cert-manager-webhook-civo [--version 0.5.4]

From local checkout

helm install --namespace cert-manager cert-manager-webhook-civo chart/cert-manager-webhook-civo

Note: The kubernetes resources used to install the Webhook should be deployed within the same namespace as the cert-manager.

Uninstalling

To uninstall the webhook run

helm uninstall --namespace cert-manager cert-manager-webhook-civo

Usage

Credentials

In order to access the CIVO API, the webhook needs an API token.

kubectl create secret generic civo-secret --from-literal=key=<YOUR_CIVO_TOKEN>

Create Issuer

Create a ClusterIssuer or Issuer resource as following:

Cluster-wide Issuer

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    # The ACME server URL
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    
    # Email address used for ACME registration
    email: [email protected] # REPLACE THIS WITH YOUR EMAIL
    
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: letsencrypt-staging

    solvers:
    - dns01:
        webhook:
          solverName: "civo"
          groupName: civo.webhook.okteto.com
          config:
            secretName: civo-secret
            secretKey: key

By default, the CIVO API token used will be obtained from the secret in the same namespace as the webhook.

Per Namespace API Tokens

If you would prefer to use separate API tokens for each namespace (e.g. in a multi-tenant environment):

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt-staging
  namespace: default
spec:
  acme:
    # The ACME server URL
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    
    # Email address used for ACME registration
    email: [email protected] # REPLACE THIS WITH YOUR EMAIL
    
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: letsencrypt-staging

    solvers:
    - dns01:
        webhook:
          solverName: "civo"
          groupName: civo.webhook.okteto.com
          config:
            secretName: civo-secret
            secretKey: key

By default, the webhook doesn't have permissions to read secrets on all namespaces. To enable this, you'll need to provide your own service account.

Create a certificate

Create your certificate resource as follows:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-cert
  namespace: cert-manager
spec:
  commonName: example.com
  dnsNames:
  - example.com # REPLACE THIS WITH YOUR DOMAIN
  issuerRef:
   name: letsencrypt-staging
   kind: ClusterIssuer
  secretName: example-cert

Development

Prerequisites

Admin access to a cluster. We recommend you launch one on CIVO.
okteto CLI
kubectl installed and configured to talk to your cluster

Launch your Development Environment

Deploy the latest version of cert-manager and cert-manager-webhook-civo as per the instructions above.
Run okteto up from the root of this repo. This will deploy your pre-configured remote development environment, and keep your file system synchronized automatically.
Run make on the remote terminal to start the webhook. This will build the webhook, start it with the required configuration, and hot reload it whenever a file is changed.
Code away!

Contributing

If you want to get involved, we'd love to receive a pull request, issues, or an offer to help. Open an issue to get started!

Maintainers:

Please see the contribution guidelines

cert-manager-webhook-civo's People

Contributors

Stargazers

Watchers

Forkers

devopstoday11 willthames malwatt kubefirst claywd j-zimnowoda mocdaniel

cert-manager-webhook-civo's Issues

unable to build kubernetes objects from release manifest

after

helm repo add jetstack https://charts.jetstack.io
helm repo add okteto https://charts.okteto.com
helm repo update
helm install cert-manager jetstack/cert-manager --namespace cert-manager --create-namespace --version v1.7.1 --set installCRDs=true

i run

helm install --namespace cert-manager cert-manager-webhook-civo okteto/cert-manager-webhook-civo

and i get

Error: INSTALLATION FAILED: unable to build kubernetes objects from release manifest: unable to recognize "": no matches for kind "APIService" in version "apiregistration.k8s.io/v1beta1"

cleanup

helm --namespace cert-manager delete cert-manager
kubectl delete namespace cert-manager
helm uninstall --namespace cert-manager cert-manager-webhook-civo

Apply fix CVE-2023-45142

Fix CVE-2023-45142 once https://github.com/cert-manager/cert-manager publishes a release that supports go.opentelemetry.io/contrib/instrumentation/net/http/otelhttp v0.44.0 (should be 1.3.2, it's already in main)

Reflector error inside logs for cert-manager-webhook-civo pod

Hello,

I am trying to get Cert Manager (with Let's Encrypt) to issue a wild card cert using DNS01 and the Civo webhook on my K8S cluster on Civo. I have Istio installed and the secret containing the cert was successfully generated in the istio-system namespace.

My website is in a different namespace so I am using https://github.com/emberstack/kubernetes-reflector to copy the cert (secret) to the namespace of my website.

On initial setup, things somehow worked and I could find the replicated secret in my website's namespace. However when I changed some certificate parameter to cause the certificate to re-issue I see that the certificate remains stuck in a pending state. Looking into the logs of the civo-webhook pod I see this:

W0520 16:34:00.041392 1 reflector.go:324] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:167: failed to list *v1beta2.PriorityLevelConfiguration: prioritylevelconfigurations.flowcontrol.apiserver.k8s.io is forbidden: User "system:serviceaccount:cert-manager:cert-manager-webhook-civo" cannot list resource "prioritylevelconfigurations" in API group "flowcontrol.apiserver.k8s.io" at the cluster scope
E0520 16:34:00.041685 1 reflector.go:138] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:167: Failed to watch *v1beta2.PriorityLevelConfiguration: failed to list *v1beta2.PriorityLevelConfiguration: prioritylevelconfigurations.flowcontrol.apiserver.k8s.io is forbidden: User "system:serviceaccount:cert-manager:cert-manager-webhook-civo" cannot list resource "prioritylevelconfigurations" in API group "flowcontrol.apiserver.k8s.io" at the cluster scope

I am still quite green with respect to Kubernetes/Istio so wondering if you could shed light on whether:

this is the wrong approach?
I need to configure permissions/roles somehow?
this is not supported by the Civo-webhook?
some other problem?

This is my ClusterIssuer yaml:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-staging-cluster
namespace: istio-system
spec:
acme:
email: [email protected]
server: https://acme-staging-v02.api.letsencrypt.org/directory
privateKeySecretRef:
name: letsencrypt-staging-cluster
solvers:
- dns01:
webhook:
solverName: "civo"
groupName: civo.webhook.okteto.com
config:
secretName: civo-secret

And my Certificate.yaml:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: mydomain-cert-staging
namespace: istio-system
spec:
secretName: mydomain-cert-staging
duration: 2160h # 90d
renewBefore: 360h # 15d
isCA: false
privateKey:
algorithm: RSA
encoding: PKCS1
size: 2048
usages:
- server auth
- client auth
commonName: "whoami.mydomain.com"
dnsNames:
- "whoami.mydomain.com"
issuerRef:
name: letsencrypt-staging-cluster
kind: ClusterIssuer
group: cert-manager.io
secretTemplate:
annotations:
reflector.v1.k8s.emberstack.com/reflection-allowed: "true"
reflector.v1.k8s.emberstack.com/reflection-allowed-namespaces: "ns-twb-staging" # Control destination namespaces.
reflector.v1.k8s.emberstack.com/reflection-auto-enabled: "true" # Auto create reflection for matching namespaces.
reflector.v1.k8s.emberstack.com/reflection-auto-namespaces: "ns-twb-staging" # Control auto-reflection namespace.

Thanks!

Run as non-root user

Hi there,
We are testing the integration of this webhook with otomi-core project.

Would you consider running it as a non-root user ?
It would strengthen the security posture and allow to define a proper security context in the values.yaml file.
E.g.:

# Pod Security Context
# ref: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
securityContext:
  runAsNonRoot: true
  seccompProfile:
    type: RuntimeDefault

# Container Security Context to be set on the controller component container
# ref: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
containerSecurityContext:
  allowPrivilegeEscalation: false
  capabilities:
    drop:
    - ALL
  readOnlyRootFilesystem: true
  runAsNonRoot: true

Cheers!

apiregistration.k8s.io/v1beta1 deprecated and removed in 1.22

See docs for details