1
0
Fork 0
kubernetes/argocd
Dustin d08cc6fb0f step-ca: Redeploy with DCH CA R3
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.
2024-02-22 07:10:01 -06:00
..
applications step-ca: Redeploy with DCH CA R3 2024-02-22 07:10:01 -06:00
README.md argocd: Deploy Argo CD 2023-10-14 10:17:04 -05:00
hooks.yaml argocd: Deploy Argo CD 2023-10-14 10:17:04 -05:00
ingress.yaml argocd: Deploy Argo CD 2023-10-14 10:17:04 -05:00
kustomization.yaml argocd: Deploy Argo CD 2023-10-14 10:17:04 -05:00
namespace.yaml argocd: Deploy Argo CD 2023-10-14 10:17:04 -05:00
oidc.config argocd: Configure SSO for CLI 2023-10-14 11:13:06 -05:00
policy.csv argocd: Deploy Argo CD 2023-10-14 10:17:04 -05:00

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.


  1. ApplicationSets are "generators" that can be used to apply applications to multiple clusters. As we only have a single cluster, it is not useful. ↩︎

  2. Argo CD includes Dex to handle authentication and authorization, but we are using Authelia instead. ↩︎