Hello everyone,
i want to create a scenario where people can change kubernetes objects without any privileges using argocd.
Also i don't want them to have privileges in argocd.
Everything should be controlled by the files in our git repo, because we are using pull requests to allow changes to it.
The problem here is that one needs privileges to create argocd applications and projects.
This can be solved by creating a project and application that watches a directory of my repo where crd files can be put. When a user uploads a application crd to the directory, then my argocd application creates the app that has now been uploaded and this newly created app then creates the kubernetes objects.
For e.g. like this:
deployer-project.yaml
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: argocd-objects
spec:
description: argocd-objects
destinations:
- namespace: '*'
server: https://kubernetes.default.svc
clusterResourceWhitelist:
- group: '*'
kind: '*'
sourceRepos:
- ssh://xxx.git
deployer-app-projects.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: argocd-projects
spec:
project: argocd-objects
source:
repoURL: ssh://xxx.git
targetRevision: HEAD
path: system-cicd/projects
destination:
server: https://kubernetes.default.svc
namespace: system-cicd
syncPolicy:
automated:
prune: true
deployer-app-apps.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: argocd-apps
spec:
project: argocd-objects
source:
repoURL: ssh://xxx.git
targetRevision: HEAD
path: system-cicd/apps
destination:
server: https://kubernetes.default.svc
namespace: system-cicd
syncPolicy:
automated:
prune: true
now one can drop files in the repo under the specified paths like this:
system-cicd/projects/system-monitoring.yaml
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: system-monitoring
spec:
description: Monitoring related stuff
destinations:
- namespace: '*'
server: https://kubernetes.default.svc
clusterResourceWhitelist:
- group: '*'
kind: '*'
sourceRepos:
- ssh://xxx.git
system-cicd/apps/prometheus-operator.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: prometheus-operator
spec:
project: system-monitoring
source:
repoURL: ssh://xxx.git
targetRevision: update-argocd
path: system-monitoring/prometheus-operator
destination:
server: https://kubernetes.default.svc
namespace: system-monitoring
syncPolicy:
automated:
prune: true
Creating new objects like this is working great.
When an application crd yaml gets removed from the directory, then it is also removed from argocd.
But the kubernetes objects - pods, svc... stay, even though the application had pruning activated.
It seems like argocd is correctly pruning the application that was removed but the pruning isn't passed down to the objects created by the application.
How can i solve this, so that, when an app crd is removed from the repo all the pods are also deleted?
Argocd version: 0.11.1
Kubernetes version: 1.13.2
When an application crd yaml gets removed from the directory, then it is also removed from argocd.
But the kubernetes objects - pods, svc... stay, even though the application had pruning activated.
It seems like argocd is correctly pruning the application that was removed but the pruning isn't passed down to the objects created by the application.
This isn't documented, but in order to achieve this behavior, the application spec in git should have the following finalizer:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: prometheus-operator
finalizers:
- resources-finalizer.argocd.argoproj.io
In normal deletes through the Argo CD API server, when it gets a delete request for an application, it does a normal kubernetes delete, but right before the deletion, it decides whether or not to add the finalizer, depending if cascaded deletion is requested.
Your use case is to have cascaded deletion, but since the Argo CD API server is not handling the delete, you miss out on this logic. Adding this finalizer will achieve your desired behavior.
resources-finalizer.argocd.argoproj.io
I wish we named this cascade-delete.argocd.argoproj.io
Thank you so much!
This is working great. I'll close this issue then
Most helpful comment
This isn't documented, but in order to achieve this behavior, the application spec in git should have the following finalizer:
In normal deletes through the Argo CD API server, when it gets a delete request for an application, it does a normal kubernetes delete, but right before the deletion, it decides whether or not to add the finalizer, depending if cascaded deletion is requested.
Your use case is to have cascaded deletion, but since the Argo CD API server is not handling the delete, you miss out on this logic. Adding this finalizer will achieve your desired behavior.