cert-manager + metallb configs
diff --git a/scripts/homelab/cert-manager-webhook-gandi/README.md b/scripts/homelab/cert-manager-webhook-gandi/README.md
new file mode 100644
index 0000000..3da4fc4
--- /dev/null
+++ b/scripts/homelab/cert-manager-webhook-gandi/README.md
@@ -0,0 +1,230 @@
+# ACME webhook for Gandi (cert-manager-webhook-gandi)
+`cert-manager-webhook-gandi` is an ACME webhook for [cert-manager]. It provides an ACME (read: Let's Encrypt) webhook for [cert-manager], which allows to use a `DNS-01` challenge with [Gandi]. This allows to provide Let's Encrypt certificates to [Kubernetes] for service protocols other than HTTP and furthermore to request wildcard certificates. Internally it uses the [Gandi LiveDNS API] to communicate with Gandi.
+
+Quoting the [ACME DNS-01 challenge]:
+
+> This challenge asks you to prove that you control the DNS for your domain name by putting a specific value in a TXT record under that domain name. It is harder to configure than HTTP-01, but can work in scenarios that HTTP-01 can’t. It also allows you to issue wildcard certificates. After Let’s Encrypt gives your ACME client a token, your client will create a TXT record derived from that token and your account key, and put that record at _acme-challenge.<YOUR_DOMAIN>. Then Let’s Encrypt will query the DNS system for that record. If it finds a match, you can proceed to issue a certificate!
+
+
+## Building
+Build the container image `cert-manager-webhook-gandi:latest`:
+
+ make build
+
+
+## Image
+Ready made images are hosted on Docker Hub ([image tags]). Use at your own risk:
+
+ bwolf/cert-manager-webhook-gandi
+
+
+### Release History
+Refer to the [ChangeLog](ChangeLog.md) file.
+
+
+## Compatibility
+This webhook has been tested with [cert-manager] v0.13.1 and Kubernetes v0.17.x on `amd64`. In theory it should work on other hardware platforms as well but no steps have been taken to verify this. Please drop me a note if you had success.
+
+
+## Testing with Minikube
+1. Build this webhook in Minikube:
+
+ minikube start --memory=4G --more-options
+ eval $(minikube docker-env)
+ make build
+ docker images | grep webhook
+
+2. Install [cert-manager] with [Helm]:
+
+ kubectl create namespace cert-manager
+ kubectl apply --validate=false -f https://raw.githubusercontent.com/jetstack/cert-manager/v0.13.1/deploy/manifests/00-crds.yaml
+
+ helm repo add jetstack https://charts.jetstack.io
+ helm install cert-manager --namespace cert-manager \
+ --set 'extraArgs={--dns01-recursive-nameservers=8.8.8.8:53\,1.1.1.1:53}' \
+ jetstack/cert-manager
+
+ kubectl get pods --namespace cert-manager --watch
+
+ **Note**: refer to Name servers in the official [documentation][setting-nameservers-for-dns01-self-check] according the `extraArgs`.
+
+ **Note**: ensure that the custom CRDS of cert-manager match the major version of the cert-manager release by comparing the URL of the CRDS with the helm info of the charts app version:
+
+ helm search repo jetstack
+
+ Example output:
+
+ NAME CHART VERSION APP VERSION DESCRIPTION
+ jetstack/cert-manager v0.13.1 v0.13.1 A Helm chart for cert-manager
+
+ Check the state and ensure that all pods are running fine (watch out for any issues regarding the `cert-manager-webhook-` pod and its volume mounts):
+
+ kubectl describe pods -n cert-manager | less
+
+
+3. Create the secret to keep the Gandi API key in the default namespace, where later on the Issuer and the Certificate are created:
+
+ kubectl create secret generic gandi-credentials \
+ --from-literal=api-token='<GANDI-API-KEY>'
+
+ **Note**: See [RBAC Authorization]:
+
+ > A Role can only be used to grant access to resources within a single namespace.
+
+ *As far as I understand cert-manager, the `Secret` must reside in the same namespace as the `Issuer` and `Certificate` resource.*
+
+4. Grant permission for the service-account to access the secret holding the Gandi API key:
+
+ kubectl apply -f rbac.yaml
+
+5. Deploy this locally built webhook (add `--dry-run` to try it and `--debug` to inspect the rendered manifests; Set `logLevel` to 6 for verbose logs):
+
+ helm install cert-manager-webhook-gandi \
+ --namespace cert-manager \
+ --set image.repository=cert-manager-webhook-gandi \
+ --set image.tag=latest \
+ --set logLevel=2 \
+ ./deploy/cert-manager-webhook-gandi
+
+ To deploy using the image from Docker Hub (for example using the `v0.1.1` tag):
+
+ helm install cert-manager-webhook-gandi \
+ --namespace cert-manager \
+ --set image.tag=v0.1.1 \
+ --set logLevel=2 \
+ ./deploy/cert-manager-webhook-gandi
+
+ Check the logs
+
+ kubectl get pods -n cert-manager --watch
+ kubectl logs -n cert-manager cert-manager-webhook-gandi-XYZ
+
+6. Create a staging issuer (email addresses with the suffix `example.com` are forbidden):
+
+ cat << EOF | sed "s/invalid@example.com/$email/" | kubectl apply -f -
+ apiVersion: cert-manager.io/v1alpha2
+ 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: invalid@example.com
+ # Name of a secret used to store the ACME account private key
+ privateKeySecretRef:
+ name: letsencrypt-staging
+ solvers:
+ - dns01:
+ webhook:
+ groupName: acme.bwolf.me
+ solverName: gandi
+ config:
+ apiKeySecretRef:
+ key: api-token
+ name: gandi-credentials
+ EOF
+
+ Check status of the Issuer:
+
+ kubectl describe issuer letsencrypt-staging
+
+ *Note*: The production Issuer is [similar][ACME documentation].
+
+7. Issue a [Certificate] for your `$DOMAIN`:
+
+ cat << EOF | sed "s/example-com/$DOMAIN/" | kubectl apply -f -
+ apiVersion: cert-manager.io/v1alpha2
+ kind: Certificate
+ metadata:
+ name: example-com
+ spec:
+ dnsNames:
+ - example-com
+ issuerRef:
+ name: letsencrypt-staging
+ secretName: example-com-tls
+ EOF
+
+ Check the status of the Certificate:
+
+ kubectl describe certificate $DOMAIN
+
+ Display the details like the common name and subject alternative names:
+
+ kubectl get secret $DOMAIN-tls -o yaml
+
+8. Issue a wildcard Certificate for your `$DOMAIN`:
+
+ cat << EOF | sed "s/example-com/$DOMAIN/" | kubectl apply -f -
+ apiVersion: cert-manager.io/v1alpha2
+ kind: Certificate
+ metadata:
+ name: wildcard-example-com
+ spec:
+ dnsNames:
+ - '*.example-com'
+ issuerRef:
+ name: letsencrypt-staging
+ secretName: wildcard-example-com-tls
+ EOF
+
+ Check the status of the Certificate:
+
+ kubectl describe certificate $DOMAIN
+
+ Display the details like the common name and subject alternative names:
+
+ kubectl get secret wildcard-$DOMAIN-tls -o yaml
+
+99. Uninstall this webhook:
+
+ helm uninstall cert-manager-webhook-gandi --namespace cert-manager
+ kubectl delete -f rbac.yaml
+ kubectl delete gandi-credentials
+
+100. Uninstalling cert-manager:
+This is out of scope here. Refer to the official [documentation][cert-manager-uninstall].
+
+
+## Development
+**Note**: If some tool (IDE or build process) fails resolving a dependency, it may be the cause that a indirect dependency uses `bzr` for versioning. In such a case it may help to put the `bzr` binary into `$PATH` or `$GOPATH/bin`.
+
+
+## Release process
+- Code changes result in a new image version and Git tag
+- Helm chart changes result in a new chart version
+- All other changes are pushed to master
+- All versions are to be documented in [ChangeLog](ChangeLog.md)
+
+
+## Conformance test
+Please note that the test is not a typical unit or integration test. Instead it invokes the web hook in a Kubernetes-like environment which asks the web hook to really call the DNS provider (.i.e. Gandi). It attempts to create an `TXT` entry like `cert-manager-dns01-tests.example.com`, verifies the presence of the entry via Google DNS. Finally it removes the entry by calling the cleanup method of web hook.
+
+**Note**: Replace the string `darwin` in the URL below with an OS matching your system (e.g. `linux`).
+
+As said above, the conformance test is run against the real Gandi API. Therefore you *must* have a Gandi account, a domain and an API key.
+
+``` shell
+cp testdata/gandi/api-key.yaml.sample testdata/gandi/api-key.yaml
+echo -n $YOUR_GANDI_API_KEY | base64 | pbcopy # or xclip
+$EDITOR testdata/gandi/api-key.yaml
+./scripts/fetch-test-binaries.sh
+TEST_ZONE_NAME=example.com. go test -v .
+```
+
+
+[ACME DNS-01 challenge]: https://letsencrypt.org/docs/challenge-types/#dns-01-challenge
+[ACME documentation]: https://cert-manager.io/docs/configuration/acme/
+[Certificate]: https://cert-manager.io/docs/usage/certificate/
+[cert-manager]: https://cert-manager.io/
+[Gandi]: https://gandi.net/
+[Gandi LiveDNS API]: https://doc.livedns.gandi.net
+[Helm]: https://helm.sh
+[image tags]: https://hub.docker.com/r/bwolf/cert-manager-webhook-gandi
+[Kubernetes]: https://kubernetes.io/
+[RBAC Authorization]: https://kubernetes.io/docs/reference/access-authn-authz/rbac/
+[setting-nameservers-for-dns01-self-check]: https://cert-manager.io/docs/configuration/acme/dns01/#setting-nameservers-for-dns01-self-check
+[cert-manager-uninstall]: https://cert-manager.io/docs/installation/uninstall/kubernetes/