feat(infisical): add organizationSlug to SecretStore for sub-org support

[devin-ai-integration]

Problem Statement

When a machine identity has access to multiple organizations (e.g. a root org identity accessing sub-organizations), there is no way to specify which organization to authenticate against in the ESO SecretStore configuration. This prevents users from using sub-orgs with the External Secrets Operator.

Reference: https://external-secrets.io/latest/provider/infisical/

Proposed Changes

Add an optional organizationSlug field to InfisicalProvider that gets passed to the Infisical universal auth login endpoint (/api/v1/auth/universal-auth/login).

The Infisical backend already supports organizationSlug on all machine identity auth endpoints — this change surfaces it in the ESO SecretStore spec.

apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
  name: infisical-store
spec:
  provider:
    infisical:
      auth:
        universalAuthCredentials:
          clientId:
            name: infisical-creds
            key: clientId
          clientSecret:
            name: infisical-creds
            key: clientSecret
      organizationSlug: "my-sub-org"   # <-- new optional field
      secretsScope:
        projectSlug: my-project
        environmentSlug: prod
        secretsPath: /

Files changed:

• apis/.../secretsstore_infisical_types.go — new OrganizationSlug field on InfisicalProvider
• pkg/.../api/api_models.go — add OrganizationSlug to login request struct
• pkg/.../api/api.go — pass slug through SetTokenViaMachineIdentity
• pkg/.../provider.go — read slug from spec and forward to auth

Checklist

• I have read the contribution guidelines
• All commits are signed with git commit --signoff
• My changes have reasonable test coverage
• All tests pass with make test
• I ensured my PR is ready for review with make reviewable

Link to Devin session: https://app.devin.ai/sessions/4892e4b77cc84275ab092612f325b3db
Requested by: @0xArshdeep

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[greptile-apps]

Greptile Summary

This PR adds an optional organizationSlug field to the Infisical SecretStore spec and threads it through to the universal-auth login endpoint, enabling machine identities that span multiple organizations (e.g. sub-orgs) to specify which org to authenticate against.

• InfisicalProvider gains an optional organizationSlug field; MachineIdentityUniversalAuthLoginRequest includes it with omitempty so it is only sent when non-empty.
• SetTokenViaMachineIdentity accepts the slug as a new parameter; provider.go reads it from the spec and forwards it at the single call site.

Confidence Score: 4/5

The change is minimal and backward-compatible — the new field is optional, defaults to empty, and the omitempty tag ensures nothing is sent to the Infisical API when it is unset. Existing stores require no changes.

The four-file change is straightforward and internally consistent. The only gap is that no test exercises the organizationSlug being read from the spec and forwarded to the login request, so a regression on that wiring would be silent.

pkg/provider/infisical/provider.go — the new propagation path through NewClient is untested

Important Files Changed

Filename	Overview
apis/externalsecrets/v1beta1/secretsstore_infisical_types.go	Adds optional OrganizationSlug string field to InfisicalProvider with correct omitempty JSON tag and kubebuilder marker; backward-compatible
pkg/provider/infisical/api/api_models.go	Adds OrganizationSlug to MachineIdentityUniversalAuthLoginRequest with omitempty; omits the field from the JSON body when empty, which is the correct behaviour
pkg/provider/infisical/api/api.go	Adds organizationSlug parameter to SetTokenViaMachineIdentity and threads it into the login request; organizationSlug is placed in the JSON body, not the URL, so no SSRF risk is introduced
pkg/provider/infisical/provider.go	Reads infisicalSpec.OrganizationSlug and forwards it to SetTokenViaMachineIdentity; correct single call-site, but no test exercises this new propagation path

_{Reviews (1): Last reviewed commit: "feat(infisical): add organizationSlug to..." | Re-trigger Greptile}

[greptile-apps]

No test coverage for organizationSlug propagation

The existing provider_test.go injects MockInfisicalClient directly (bypassing SetTokenViaMachineIdentity), so there is no test that exercises the new organizationSlug path through NewClient. If a future refactor accidentally drops the slug from the call, the test suite would not catch it. Consider adding an integration-style test or extending MockInfisicalClient.MachineIdentityLoginViaUniversalAuth to capture and assert the OrganizationSlug field.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!