I never ended up using _Step CA_ for anything, since I was initially focused on the SSH CA feature and I was unhappy with how it worked (which led me to write _SSHCA_). I didn't think about it much until I was working on deploying Grafana Loki. For that project, I wanted to use a certificate signed by a private CA instead of the wildcard certificate for _pyrocufflink.blue_. So, I created *DCH CA R3* for that purpose. Then, for some reason, I used the exact same procedure to fetch the certificate from Kubernetes as I had set up for the _pyrocufflink.blue_ wildcard certificate, as used by Frigate. This of course defeated the purpose, since I could have just as easily used the wildcard certificate in that case. When I discovered that Grafana Loki expects to be deployed behind a reverse proxy in order to implement access control, I took the opportunity to reevaluate the certificate issuance process. Since a reverse proxy is required to implement the access control I want (anyone can push logs but only authenticated users can query them), it made sense to choose one with native support for requesting certificates via ACME. This would eliminate the need for `fetchcert` and the corresponding Kubernetes API token. Thus, I ended up deciding to redeploy _Step CA_ with the new _DCH CA R3_ for this purpose. |
||
---|---|---|
.. | ||
applications | ||
README.md | ||
hooks.yaml | ||
ingress.yaml | ||
kustomization.yaml | ||
namespace.yaml | ||
oidc.config | ||
policy.csv |
README.md
Argo CD
Argo CD is a declarative GitOps continuous delivery tool, which allows developers to define and control deployment of Kubernetes application resources from within their existing Git workflow.
kubectl apply -k argocd
kubectl apply -f argocd/applications
Components
Argo CD consists of several components, some of which are not used:
- Application Controller
- Repository Service
- Web Server
- Notification Controller
- ApplicationSet Controller1
- Dex Server2
Applications
Applications are the core resource in Argo CD. They form a collection of resources associated with a particular application deployment. They are themselves defined as Kubernetes resources (see applications).
Git Webhook
Argo CD will automatically refresh the desired state of applications whenever a changeset is pushed to the Git repository where manifests are stored. The infra/kubernetes repository has a Webhook configured in Gitea that notifies the Argo CD server on Git push events.