Gitlab Variables environment_scope not honoured

[AlexEndris]

I'm facing the issue that ExternalSecrets doesn't seem to correctly filter the variables using Gitlab Variables. The SecretStore is capable of retrieving a secret of environment "b" even though it's being restricted to "a". Let's say I have the secrets "TEST_SECRET_A" (environment "a") and "TEST_SECRET_B" (environment "b"), neither secret exists in any other environment.

Using this secretstore:

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: a-secrets
  namespace: default
spec:
  provider:
    gitlab:
      auth:
        SecretRef:
          accessToken:
            name: xxx
            key: xxx
      projectID: "xxx"
      inheritFromGroups: false
      environment: a

Adding an ExternalSecret resource like this, actually retrieves the secret:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: gitlab-external-secret-b
  namespace: default
spec:
  refreshInterval: 1m

  secretStoreRef:
    kind: SecretStore
    name: a-secrets

  target:
    name: b-secret 
    creationPolicy: Owner

  data:
    - secretKey: secretKey
      remoteRef: 
        key: TEST_SECRET_B

Trying the same using the gitlab API with the filter for the environment_scope of "a" correctly returns "404 Variable Not Found".

Am I doing something wrong or is this indeed a bug?

[svanharmelen]

I have no idea... Could be an issue with the right of the user you are making the API call with. In most of there cases I suggest you try to verify the GitLab API and the used credentials by constructing a cURL call to do what you want/expect.

If that works and it doesn't work with this package then please post the info/output of your test so I can have a look.

[AlexEndris]

First, I realised I'm in the wrong place... For what ever reason I thought I was in the github repository of External Secrets.

So, even though I did what you said (verify it with the same token through curl), I'm not sure it's go-gitlab that's the issue here or it's actual usage... I'll close this issue and re-open it where it properly belongs. Sorry for the inconvenience!