Does removing daemon set deletes the plugin from node as well?

[smartaquarius10]

Hello,

If we delete daemon set, does it auto removes the downloaded plugin and config files from kubernetes node or should we have to restart the nodes.

Actually there is nothing I can see of binary deletion or any prestop hook in daemon set. If my understanding is correct isn’t this conflict with kubelet even after uninstalling the helm chart.

Furthermore, as far as I know this command is making change in cri_auth_config.yaml with the help of downloaded binary.

nsenter -t 1 -m -p -- ${JFROG_CREDENTIAL_PROVIDER_BINARY_DIR}/{{ .name }} add-provider-config --yaml --provider-home "${KUBELET_CREDENTIAL_PROVIDER_CONFIG_DIR}" --provider-config "${KUBELET_CREDENTIAL_PROVIDER_CONFIG_FILE_NAME}"

Is there anyway to roll it back without restarting nodes after remove the plugin?

Kind Regards,

[RobinDuhan]

It doesn't yet. We will eventually add it, but for now you would need to restart the nodes. I understand the pain here. We would add a helm uninstall that will remove our configuration.

[smartaquarius10]

@RobinDuhan Is there any other solution for GCP specifically rather than this plugin?

[RobinDuhan]

Do you want to look at https://github.com/jfrog/jfrog-registry-operator - internals are same, except it's not a kubelet plugin.

[smartaquarius10]

@RobinDuhan but I though it doesn't support GCP.. Is it? Because we are already using this with AWS.. If it supports GKE then its great as we dont have to make much changes in our environment?

[smartaquarius10]

@RobinDuhan Would really appreciate if you can share some details around this. It would be awesome. :)

[RobinDuhan]

Responded on the other thread. It does not support GCP, you are right. I was a little quick to think of the registry operator.

[smartaquarius10]

Hello @RobinDuhan ,

How to set this environment variable via helm chart deployment cloud_provider. Currently, we have v1.1.1

If we don't set it, every time plugin performs these checks

[JFROG CREDENTIALS PROVIDER] 2026/05/19 11:32:32 logger.go:40: [INFO] cloud_provider from env:
[JFROG CREDENTIALS PROVIDER] 2026/05/19 11:32:32 logger.go:40: [INFO] Checking if cloud provider is AWS
[JFROG CREDENTIALS PROVIDER] 2026/05/19 11:32:32 logger.go:40: [INFO] TOKEN_URL :http://169.254.169.254/latest/api/token
[JFROG CREDENTIALS PROVIDER] 2026/05/19 11:32:32 logger.go:40: [INFO] Checking if cloud provider is Azure
[JFROG CREDENTIALS PROVIDER] 2026/05/19 11:32:32 logger.go:40: [INFO] Azure metadata server response status code: 404
[JFROG CREDENTIALS PROVIDER] 2026/05/19 11:32:32 logger.go:40: [INFO] Checking if cloud provider is Google
[JFROG CREDENTIALS PROVIDER] 2026/05/19 11:32:32 logger.go:40: [INFO] Google metadata server response status code: 200

Second query is where to check the logs of file /var/log/jfrog-credential-provider.log without going inside pod. Does latest helm chart support containerLogging feature?

[RobinDuhan]

Hi @smartaquarius10 , I missed responding. I'll release a version of chart today that supports containerLogging.

For cloud_provider, it isn't supported through the chart. I'll take that feedback and introduce it. I think I may just add an extra environment variable section for this to encompass most use-cases.

Thank you for diving deep into our solution!

[smartaquarius10]

Thank @RobinDuhan today I tested workload identity approach and without binding its working. As mentioned earlier, plugin code only verifying jfrog-exhange annotation and passing the kubelet token directly to the jfrog. The service account annotation is needed just to fulfill the requirement of token attributes which is mentioned here

Even deleted the IAM created still it worked. Will be raising a jfrog support ticket today.

[RobinDuhan]

@smartaquarius10 Oh, interesting. Could you share your custom-values.yaml with redacted sensitive info, and the service account yaml too maybe?

[smartaquarius10]

@RobinDuhan Does workload identity authentication via this plugin support gcp Kubernetes version 1.34+?

I don’t think it currently works because kubelet cannot request a token for a custom audience unless:

• the required RBAC changes are applied to the cluster, or
• the pod spec already contains the audience in a projected service account token volume.

Details are mentioned here

[gss2002]

It also doesnt update the values when changes are made to the helm chart. You have to manually cleanup the nodes or have the nodegroups replaced..

[RobinDuhan]

@gss2002 That's not true. Helm upgrades would update the configuration, but you may need to rollout restart your daemonset.