Open Blamas opened 2 years ago
I have same problem. I have configured helm repos with credentials in argo, but cannot use them in CMP sidecar. Also similar thing with kustomize and private git repositories in resources.
@crenshaw-dev Please don't deprecate current plugin via configmap, as sidecars approach is not usable and incomplete.
@mmalyska the deprecation is important, because argocd-cm plugins present major security issues. But I agree, support should not be completely removed until this issue is resolved.
Having the same issue, going to revert back to older version. Is there a chance a fix might be available soon @crenshaw-dev?
Hi, I am not sure if my issue is related to the above. I am able go use plugins via the "old" way by loading plugins via configMap; now I am trying to use the new way via sidecar. Even if my repository are public (my own helm chart + prometheus one) I am still getting:
time="2022-11-10T13:22:21Z" level=info msg="Generating manifests with no request-level timeout"
time="2022-11-10T13:22:21Z" level=info msg="/bin/sh -c helm dependency build" dir=/tmp/_cmp_server/94c806a6-ce48-407d-99a5-5f34df9962c5/charts/monitoring execID=91f27
time="2022-11-10T13:22:22Z" level=error msg="`/bin/sh -c helm dependency build` failed exit status 1: Error: no cached repository for helm-manager-a3d71d79da3a7e97fc44127f373aa765c1b71499cb48cdf46a0c10608bd437bc found. (try 'helm repo update'): open /.cache/helm/repository/helm-manager-a3d71d79da3a7e97fc44127f373aa765c1b71499cb48cdf46a0c10608bd437bc-index.yaml: no such file or directory" execID=91f27
time="2022-11-10T13:22:22Z" level=error msg="finished streaming call with code Unknown" error="error generating manifests: `/bin/sh -c helm dependency build` failed exit status 1: Error: no cached repository for helm-manager-a3d71d79da3a7e97fc44127f373aa765c1b71499cb48cdf46a0c10608bd437bc found. (try 'helm repo update'): open /.cache/helm/repository/helm-manager-a3d71d79da3a7e97fc44127f373aa765c1b71499cb48cdf46a0c10608bd437bc-index.yaml: no such file or directory" grpc.code=Unknown grpc.method=GenerateManifest grpc.service=plugin.ConfigManagementPluginService grpc.start_time="2022-11-10T13:22:21Z" grpc.time_ms=804.455 span.kind=server system=grpc
Should the cache be mounted across the 2 containers?
Thanks
@kxs-sindrakumar we won't be able to revert, because the solution I merged was insecure. We can't allow all CMPs full access to repo creds. There needs to be some kind of system for an admin to permit CMPs to access secrets for certain repos.
@yellowhat this looks like a different issue, can you open a new one? I don't think the Helm cache needs to be shared, but I could be wrong about that. Maybe just need to mount an emptyDir for the Helm cache, similar to how it's done on the main repo-server container. But I'd avoid sharing resources unless absolutely necessary.
@yellowhat You need to fetch dependency yourself in plugin helm dependency update
or when doing the template you need to use option --dependency-update
ex. helm template . --dependency-update
to make help auto fetch dependencies in plugin(because there is no share of helm cache in plugin sidecar).
Yes the init.command
is helm dependency update
.
I will try to mount the helm-working-dir
volume.
I can confirm that was due to a missing folder.
I am assuming that it is looking for the env var HELM_CACHE_HOME
, HELM_CONFIG_HOME
, HELM_DATA_HOME
.
The following works for me:
repoServer:
replicas: 1
extraContainers:
- name: cmp
command: ["/var/run/argocd/argocd-cmp-server"]
# Use argocd as it contains helm and kustomize
image: quay.io/argoproj/argocd:latest
securityContext:
runAsNonRoot: true
runAsUser: 999
env:
- name: HELM_CACHE_HOME
value: /helm-working-dir
- name: HELM_CONFIG_HOME
value: /helm-working-dir
- name: HELM_DATA_HOME
value: /helm-working-dir
volumeMounts:
- name: var-files
mountPath: /var/run/argocd
- name: plugins
mountPath: /home/argocd/cmp-server/plugins
- name: cmp-plugin
mountPath: /home/argocd/cmp-server/config/plugin.yaml
subPath: plugin.yaml
- name: cmp-tmp
mountPath: /tmp
- name: helm-temp-dir
mountPath: /helm-working-dir
volumes:
- name: cmp-plugin
configMap:
name: cmp-plugin
- name: cmp-tmp
emptyDir: {}
# avoid to share the volume helm-working-dir
- name: helm-temp-dir
emptyDir: {}
I think the documentation should include an example for helm/kustomize usecases.
@yellowhat I'd be happy to review a docs PR if you have a chance to write it up!
Have you tried mounting a different Helm temp dir for the sidecar vs. the one used by the main repo-server container?
The point of the sidecars is to be as stateless/ephemeral and share as little information as possible with the main container.
As you can see in my example above, I am mounting helm-temp-dir
not helm-working-dir
volume (the one mounted on the repo-server
container).
My usecase seems to work with either volumes.
I am not sure if sharing helm-working-dir
would be required for a private repository.
@crenshaw-dev how are we supposed to use this side car for kustomize if we have a private repo to another private repo. When CMP runs kustomize build on the first repo, it doesn't seem to generate the manifest. The secrets for both repos are the same
@crenshaw-dev how are we supposed to use this side car for kustomize if we have a private repo to another private repo. When CMP runs kustomize build on the first repo, it doesn't seem to generate the manifest. The secrets for both repos are the same
Workaround for the meantime:
I managed to get it working by mounting the ssh credentials for pulling the private repo in the argocd-repo-server
. Created ssh configmaps and secrets and then mounted them all. Here is an example patch:
apiVersion: apps/v1
kind: Deployment
metadata:
name: argocd-repo-server
spec:
template:
spec:
volumes:
- name: ssh-config
configMap:
name: argocd-ssh-config
- name: ssh-key
secret:
secretName: argocd-ssh
- name: ssh-known-hosts
configMap:
name: argocd-ssh-known-hosts-cm
containers:
- name: argocd-repo-server
volumeMounts:
- mountPath: /home/argocd/.ssh/config
name: ssh-config
subPath: ssh-config
- mountPath: /home/argocd/.ssh/id_rsa
name: ssh-key
subPath: argocd-ssh
- mountPath: /home/argocd/.ssh/known_hosts
name: ssh-known-hosts
subPath: ssh_known_hosts
Then create a secret ssh-key
with the pem and set ssh-config
configmap like
Host repository.org
IdentityFile ~/.ssh/id_rsa
The configmap ssh-known-hosts
already exists as part of the ArgoCD deployment.
If deprecation of CMP through argocd-cm is to be done by 2.7, I feel like this issue should also target milestone v2.7
.
Or, at the very least, documentation should be provided of a satisfactory workaround.
@jemag this limitation is not unique to sidecar CMPs. Starting with (iirc) 2.3, no plugins are given access to Argo CD's repo credentials.
hmm that is weird. I currently use a kustomized-helm plugin through the configmap with private repositories and haven't faced any issues. Haven't configured any particular workaround either, just using the classic:
configManagementPlugins: |
- name: kustomized-helm
init:
command: ["/bin/sh", "-c"]
args: ["helm dependency build || true"]
generate:
command: ["/bin/sh", "-c"]
args: ["helm template . --name-template $ARGOCD_APP_NAME --namespace $ARGOCD_APP_NAMESPACE --include-crds -f $ARGOCD_ENV_VALUES_PATH > all.yaml && kustomize build $ARGOCD_ENV_OVERLAY_PATH"]
Hm... there's a pretty good chance I'm just straight-up wrong on this one. I need to dive in and make sure what the current state is. Won't be able to do that for a little while though. :-(
just as a clarification on my comment @crenshaw-dev , it worked with 2.5.1
, however it indeed does not seem to work anymore if I upgrade past 2.5.2
(currenty experimenting with 2.6.0
), see https://github.com/argoproj/argo-cd/issues/11747
Not sure if there is a breaking change notice that I missed, but seems weird that this would change within 2.5.x
I must say we ran into this problem when upgrading from 2.7.3 to 2.8.2, this only occurs if the helm chart itself is loaded from an external private repository (locally cached helm charts worked as usual, also plugins like helm-secrets worked too):
no cached repository for helm-manager-6d77cc5d2b67cb858de97b5e4ca5537b886f133c28a9a2824bc8122543bd28d4 found.
(try 'helm repo update'): open /helm-working-dir/repository/helm-manager-6d77cc5d2b67cb858de97b5e4ca5537b886f133c28a9a2824bc8122543bd28d4-index.yaml: no such file or directory"
I am trying to check our CMP custom image for any misconfigurations as well as initcontainer for repoServer (we hit this on RepoServer it seems).
EDIT:
I must say our initContainer setup for RepoServer does not follow the official docs anymore as we are setting HELM_PLUGINS env ourselves and nothing else (no cache dir or other ones listed in the documentation for 2.8.2):
env:
- name: HELM_PLUGINS
value: /custom-tools/helm-plugins/
And then installing plugins like so:
args:
- |
mkdir -p /custom-tools/helm-plugins
wget -qO- https://github.com/jkroepke/helm-secrets/releases/download/v${HELM_SECRETS_VERSION}/helm-secrets.tar.gz | tar -C /custom-tools/helm-plugins -xzf-;
I will give it a go to refactor the initContainer to be in tune with the official guide and set all the vars described there: https://argo-cd.readthedocs.io/en/stable/user-guide/helm/#using-initcontainers
Well, after some testing we found out that the issue occurs for us (again, when migrating from 2.7.3 to 2.8.x) when you have dependency in requirements.yaml
dependencies:
- name: xxx
version: x.y.z
repository: https://example.com/helm
What works is adding this section to chart.yaml:
apiVersion: v1
name: myapp
version: 1.0.0
dependencies:
- name: xxx
version: x.y.z
repository: https://example.com/helm
Hey, is there a solution for this?
Checklist:
argocd version
.Describe the bug
I cannot use my custom cmp sidecar plugin with private helm dependencies. It seems that the cached helm registry is not passed to the sidecar plugin. When I use the same Application without any plugin it works just fine. The plugin works when i'm not using private dependencies.
To Reproduce
With a custom sidecar cmp plugin try to use an Application with as source a git path containing an helm chart using private dependencies.
Application :
In private-repo/k8s/path/application
Expected behavior
The helm chart fetch it's dependencies with the credentials from the repo server.
Version
Logs