Secrets Provider To handle more than 50 Conjur secrets, you can set up multiple Secrets Providers. When we attempt to create 2nd secret provider it fails, Error: INSTALLATION FAILED: rendered manifests contain a resource that already exists.

[sbhakta99]

Summary

*Secrets Provider To handle more than 50 Conjur secrets, you can set up multiple Secrets Providers. When we attempt to create 2nd secret provider it fails, Error: INSTALLATION FAILED: rendered manifests contain a resource that already exists.

Steps to Reproduce

We are following the statement from following doc:
https://docs.cyberark.com/conjur-enterprise/13.3/en/Content/Integrations/k8s-ocp/cjr-k8s-jwt-sp-ac.htm?tocpath=Integrations%7COpenShift%252FKubernetes%7CApp%20owner%253A%20Set%20up%20workloads%20in%20Kubernetes%7CSet%20up%20workloads%20(JWT-based%20authn)%7CSecrets%20Provider%20for%20Kubernetes%7C_____2

We are able to create first secret provider but when we attempt the 2nd one it fails

Expected Results

A clear and concise description of what you expected to happen.

Actual Results

A clear and concise description of what actually did happen. Include logs and
screens shots, whenever possible

Reproducible

• [ X] Always
• Sometimes
• Non-Reproducible

Version/Tag number

What version of the product are you running? Any version info that you can
share is helpful. For example, you might give the version from Docker logs,
the Docker tag, a specific download URL, the output of the /info route, etc.

Environment setup

• Can you describe the environment in which this product is running? Is it running on a VM / in a container / in a cloud?
• Which cloud provider? Which container orchestrator (including version)?
• The more info you can share about your runtime environment, the better we may be able to reproduce the issue.

Additional Information

We are following the statement from following doc:
https://docs.cyberark.com/conjur-enterprise/13.3/en/Content/Integrations/k8s-ocp/cjr-k8s-jwt-sp-ac.htm?tocpath=Integrations%7COpenShift%252FKubernetes%7CApp%20owner%253A%20Set%20up%20workloads%20in%20Kubernetes%7CSet%20up%20workloads%20(JWT-based%20authn)%7CSecrets%20Provider%20for%20Kubernetes%7C_____2

We are able to create first secret provider but when we attempt the 2nd one it fails
name of first one: sp-test-dev-dis
name of second one: sp-test-dev-dis2

helm install sp-test-dev-dis cyberark/secrets-provider -f test-dev-dis_disvc-dev.yaml --set environment.conjur.conjurConnConfigMap=conjur-connect -n disvc-dev

NAME: sp-test-dev-dis
LAST DEPLOYED: Thu Aug 22 12:18:10 2024
NAMESPACE: disvc-dev
STATUS: deployed
REVISION: 1
TEST SUITE: None

Deploy the Secrets Provider using Helm for 2nd
helm install sp-test-dev-dis2 cyberark/secrets-provider -f test-dev-dis_disvc-dev.yaml --set environment.conjur.conjurConnConfigMap=conjur-connect -n disvc-dev
Error: INSTALLATION FAILED: rendered manifests contain a resource that already exists. Unable to continue with install: ServiceAccount "secrets-provider-service-account" in namespace "disvc-dev" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "sp-test-dev-dis2": current value is "sp-test-dev-dis"

[sbhakta99]

Hello, can anyone help with this?

[sbhakta99]

Support Recommended:
By looking at the configuration for secrets providers helm chart, it looks like the rbac.create control the creation of SA,

We would propose to create them only for the first deployment and disable creation for the following ones. This way there shouldn't be any conflicts of resource ownership for following helm deployments.

[sbhakta99]

I proposed the following option if supported:
That way if secrets-provider-2 is deleted/redeployed because of a new secret entry, it wouldn't affect secrets-provider-3 svc/role/rolebinding ?

secrets-provider-2
rbac:
create: true
roleName: secrets-provider-role-2
roleBindingName: secrets-provider-role-binding-2
serviceAccount:
name: secrets-provider-service-account-2

secrets-provider-3
rbac:
create: true
roleName: secrets-provider-role-3
roleBindingName: secrets-provider-role-binding-3
serviceAccount:
name: secrets-provider-service-account-3

[sbhakta99]

Cyberark Support Indicated: Yes, that would be even better way of avoiding the ownership conflict, and would make the deployments independent. Just please make sure that all of the names are unique within a given namespace:
rbac.roleBindingName, rbac.serviceAccount.name, rbac.roleName

This did work and 2nd secret provider did deploy it no resource conflicts.