VSO helm test does not take into account the service account

[ogirardot]

Describe the bug When launching the helm tests, they do not run as a service account with the proper credentials and they fail with :

{"level":"info","ts":"2023-11-28T23:43:56Z","logger":"initCachingClientFactory","msg":"Initializing the CachingClientFactory"}
2023-11-28T23:43:56Z    ERROR   setup   Failed to setup the Vault ClientFactory {"error": "secrets is forbidden: User \"system:serviceaccount:<namespace>:default\" cannot create resource \"secrets\" in API group \"\" in the namespace \"<namespace>\""}
main.main
        /home/runner/work/vault-secrets-operator/vault-secrets-operator/main.go:215
runtime.main
        /opt/hostedtoolcache/go/1.21.3/x64/src/runtime/proc.go:267

To Reproduce Steps to reproduce the behavior:

1. Launch a k3d cluster
2. install vault + vso

Expected behavior Maybe the test should use the same SA that vso uses ?

[jayamorin]

Create role and rolebinding.

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: default
  namespace: vault-secrets-operator-system
rules:
  - apiGroups:
    - ""
    resources:
    - secrets
    verbs:
    - create
    - get
    - delete
    - deletecollection
  - apiGroups:
    - coordination.k8s.io
    resources:
    - leases
    verbs:
    - get
    - watch
    - list

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: default
  namespace: vault-secrets-operator-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: default
subjects:
- kind: ServiceAccount
  name: default
  namespace: vault-secrets-operator-system

Works for me.

[Feyd-Rauth]

I have the same issue. I agree that it would be much better if the test used the same SA as VSO