Skip to content

fix(gcp): makes workload identity parameters optional#4622

Merged
gusfcarvalho merged 4 commits intomainfrom
gc/fix-gcp-crds
Apr 8, 2025
Merged

fix(gcp): makes workload identity parameters optional#4622
gusfcarvalho merged 4 commits intomainfrom
gc/fix-gcp-crds

Conversation

@gusfcarvalho
Copy link
Copy Markdown
Member

@gusfcarvalho gusfcarvalho commented Apr 7, 2025

Fixes #4616

@gusfcarvalho gusfcarvalho requested a review from a team as a code owner April 7, 2025 09:06
@gusfcarvalho gusfcarvalho requested a review from knelasevero April 7, 2025 09:06
gusfcarvalho and others added 3 commits April 7, 2025 06:06
@gusfcarvalho
fix(gcp): makes workload identity parameters optional
26657d9 
Signed-off-by: Gustavo Carvalho <gustavo@externalsecrets.com>
@gusfcarvalho
fix: helm test update
3927e0f 
Signed-off-by: Gustavo Carvalho <gustavo@externalsecrets.com>
@gusfcarvalho
Merge branch 'main' into gc/fix-gcp-crds
c692a32
@sonarqubecloud
Copy link
Copy Markdown

sonarqubecloud bot commented Apr 8, 2025

Quality Gate Passed Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

@gusfcarvalho gusfcarvalho merged commit 3cebf41 into main Apr 8, 2025
22 checks passed
@gusfcarvalho gusfcarvalho deleted the gc/fix-gcp-crds branch April 8, 2025 11:31
This was referenced Jun 20, 2025
Open
Open
Merged
Closed
patjlm added a commit to patjlm/external-secrets that referenced this pull request Feb 3, 2026
@patjlm
feat(gcpsm): auto-detect projectID from GCP metadata server
1c98b15 
Extends metadata server auto-detection to include the projectID field
when using Workload Identity in GKE. Builds upon the foundation from
external-secrets#4575, external-secrets#4622, and external-secrets#5208 which made cluster identity parameters optional.

Problem:
While cluster identity parameters (ClusterLocation, ClusterName,
ClusterProjectID) became optional via metadata server lookup, the main
projectID field (specifying where secrets are stored) remained required.
This forced users to parameterize SecretStore configurations per-cluster,
preventing static GitOps deployments via Config Sync/Fleet in
multi-project environments.

Solution:
When projectID is omitted from SecretStore/ClusterSecretStore spec:
1. clusterProjectID() falls back to GCP metadata server
2. NewClient() populates gcpStore.ProjectID with detected value

This allows the operator to access secrets in the same project as the
GKE cluster without explicit configuration.

Use Cases:
- Portable SecretStore configs across multiple GCP projects
- Static bootstrap manifests via Config Sync without parameterization
- Eliminates cross-cluster network dependencies for private GKE clusters

Changes:
- provider.go: Add metadata server fallback in clusterProjectID()
- provider.go: Populate gcpStore.ProjectID from clusterProjectID when empty
- workload_identity_test.go: Add TestClusterProjectIDMetadataFallback
- docs: Document projectID auto-detection feature with examples

Note: projectID remains required when using static service account
credentials, running outside GKE, or accessing secrets in a different
project than the GKE cluster.

Signed-off-by: Patrick Martin <patmarti@redhat.com>
@patjlm patjlm mentioned this pull request Feb 3, 2026
Merged
5 tasks
patjlm added a commit to patjlm/external-secrets that referenced this pull request Feb 9, 2026
@patjlm
feat(gcpsm): auto-detect projectID from GCP metadata server
43811a3 
Extends metadata server auto-detection to include the projectID field
when using Workload Identity in GKE. Builds upon the foundation from
external-secrets#4575, external-secrets#4622, and external-secrets#5208 which made cluster identity parameters optional.

Problem:
While cluster identity parameters (ClusterLocation, ClusterName,
ClusterProjectID) became optional via metadata server lookup, the main
projectID field (specifying where secrets are stored) remained required.
This forced users to parameterize SecretStore configurations per-cluster,
preventing static GitOps deployments via Config Sync/Fleet in
multi-project environments.

Solution:
When projectID is omitted from SecretStore/ClusterSecretStore spec:
1. clusterProjectID() falls back to GCP metadata server
2. NewClient() populates gcpStore.ProjectID with detected value

This allows the operator to access secrets in the same project as the
GKE cluster without explicit configuration.

Use Cases:
- Portable SecretStore configs across multiple GCP projects
- Static bootstrap manifests via Config Sync without parameterization
- Eliminates cross-cluster network dependencies for private GKE clusters

Changes:
- provider.go: Add metadata server fallback in clusterProjectID()
- provider.go: Populate gcpStore.ProjectID from clusterProjectID when empty
- workload_identity_test.go: Add TestClusterProjectIDMetadataFallback
- docs: Document projectID auto-detection feature with examples

Note: projectID remains required when using static service account
credentials, running outside GKE, or accessing secrets in a different
project than the GKE cluster.

Signed-off-by: Patrick Martin <patmarti@redhat.com>
patjlm added a commit to patjlm/external-secrets that referenced this pull request Mar 4, 2026
@patjlm
feat(gcpsm): auto-detect projectID from GCP metadata server
9bd9b89 
Extends metadata server auto-detection to include the projectID field
when using Workload Identity in GKE. Builds upon the foundation from
external-secrets#4575, external-secrets#4622, and external-secrets#5208 which made cluster identity parameters optional.

Problem:
While cluster identity parameters (ClusterLocation, ClusterName,
ClusterProjectID) became optional via metadata server lookup, the main
projectID field (specifying where secrets are stored) remained required.
This forced users to parameterize SecretStore configurations per-cluster,
preventing static GitOps deployments via Config Sync/Fleet in
multi-project environments.

Solution:
When projectID is omitted from SecretStore/ClusterSecretStore spec:
1. clusterProjectID() falls back to GCP metadata server
2. NewClient() populates gcpStore.ProjectID with detected value

This allows the operator to access secrets in the same project as the
GKE cluster without explicit configuration.

Use Cases:
- Portable SecretStore configs across multiple GCP projects
- Static bootstrap manifests via Config Sync without parameterization
- Eliminates cross-cluster network dependencies for private GKE clusters

Changes:
- provider.go: Add metadata server fallback in clusterProjectID()
- provider.go: Populate gcpStore.ProjectID from clusterProjectID when empty
- workload_identity_test.go: Add TestClusterProjectIDMetadataFallback
- docs: Document projectID auto-detection feature with examples

Note: projectID remains required when using static service account
credentials, running outside GKE, or accessing secrets in a different
project than the GKE cluster.

Signed-off-by: Patrick Martin <patmarti@redhat.com>
patjlm added a commit to patjlm/external-secrets that referenced this pull request Mar 6, 2026
@patjlm
feat(gcpsm): auto-detect projectID from GCP metadata server
a1240cb 
Extends metadata server auto-detection to include the projectID field
when using Workload Identity in GKE. Builds upon the foundation from
external-secrets#4575, external-secrets#4622, and external-secrets#5208 which made cluster identity parameters optional.

Problem:
While cluster identity parameters (ClusterLocation, ClusterName,
ClusterProjectID) became optional via metadata server lookup, the main
projectID field (specifying where secrets are stored) remained required.
This forced users to parameterize SecretStore configurations per-cluster,
preventing static GitOps deployments via Config Sync/Fleet in
multi-project environments.

Solution:
When projectID is omitted from SecretStore/ClusterSecretStore spec:
1. clusterProjectID() falls back to GCP metadata server
2. NewClient() populates gcpStore.ProjectID with detected value

This allows the operator to access secrets in the same project as the
GKE cluster without explicit configuration.

Use Cases:
- Portable SecretStore configs across multiple GCP projects
- Static bootstrap manifests via Config Sync without parameterization
- Eliminates cross-cluster network dependencies for private GKE clusters

Changes:
- provider.go: Add metadata server fallback in clusterProjectID()
- provider.go: Populate gcpStore.ProjectID from clusterProjectID when empty
- workload_identity_test.go: Add TestClusterProjectIDMetadataFallback
- docs: Document projectID auto-detection feature with examples

Note: projectID remains required when using static service account
credentials, running outside GKE, or accessing secrets in a different
project than the GKE cluster.

Signed-off-by: Patrick Martin <patmarti@redhat.com>
patjlm added a commit to patjlm/external-secrets that referenced this pull request Mar 6, 2026
@patjlm
feat(gcpsm): auto-detect projectID from GCP metadata server
7293c3b 
Extends metadata server auto-detection to include the projectID field
when using Workload Identity in GKE. Builds upon the foundation from
external-secrets#4575, external-secrets#4622, and external-secrets#5208 which made cluster identity parameters optional.

Problem:
While cluster identity parameters (ClusterLocation, ClusterName,
ClusterProjectID) became optional via metadata server lookup, the main
projectID field (specifying where secrets are stored) remained required.
This forced users to parameterize SecretStore configurations per-cluster,
preventing static GitOps deployments via Config Sync/Fleet in
multi-project environments.

Solution:
When projectID is omitted from SecretStore/ClusterSecretStore spec:
1. clusterProjectID() falls back to GCP metadata server
2. NewClient() populates gcpStore.ProjectID with detected value

This allows the operator to access secrets in the same project as the
GKE cluster without explicit configuration.

Use Cases:
- Portable SecretStore configs across multiple GCP projects
- Static bootstrap manifests via Config Sync without parameterization
- Eliminates cross-cluster network dependencies for private GKE clusters

Changes:
- provider.go: Add metadata server fallback in clusterProjectID()
- provider.go: Populate gcpStore.ProjectID from clusterProjectID when empty
- workload_identity_test.go: Add TestClusterProjectIDMetadataFallback
- docs: Document projectID auto-detection feature with examples

Note: projectID remains required when using static service account
credentials, running outside GKE, or accessing secrets in a different
project than the GKE cluster.

Signed-off-by: Patrick Martin <patmarti@redhat.com>
patjlm added a commit to patjlm/external-secrets that referenced this pull request Mar 6, 2026
@patjlm
feat(gcpsm): auto-detect projectID from GCP metadata server
a5416cc 
Extends metadata server auto-detection to include the projectID field
when using Workload Identity in GKE. Builds upon the foundation from
external-secrets#4575, external-secrets#4622, and external-secrets#5208 which made cluster identity parameters optional.

Problem:
While cluster identity parameters (ClusterLocation, ClusterName,
ClusterProjectID) became optional via metadata server lookup, the main
projectID field (specifying where secrets are stored) remained required.
This forced users to parameterize SecretStore configurations per-cluster,
preventing static GitOps deployments via Config Sync/Fleet in
multi-project environments.

Solution:
When projectID is omitted from SecretStore/ClusterSecretStore spec:
1. clusterProjectID() falls back to GCP metadata server
2. NewClient() populates gcpStore.ProjectID with detected value

This allows the operator to access secrets in the same project as the
GKE cluster without explicit configuration.

Use Cases:
- Portable SecretStore configs across multiple GCP projects
- Static bootstrap manifests via Config Sync without parameterization
- Eliminates cross-cluster network dependencies for private GKE clusters

Changes:
- provider.go: Add metadata server fallback in clusterProjectID()
- provider.go: Populate gcpStore.ProjectID from clusterProjectID when empty
- workload_identity_test.go: Add TestClusterProjectIDMetadataFallback
- docs: Document projectID auto-detection feature with examples

Note: projectID remains required when using static service account
credentials, running outside GKE, or accessing secrets in a different
project than the GKE cluster.

Signed-off-by: Patrick Martin <patmarti@redhat.com>
patjlm added a commit to patjlm/external-secrets that referenced this pull request Mar 11, 2026
@patjlm
feat(gcpsm): auto-detect projectID from GCP metadata server
83ad7d0 
Extends metadata server auto-detection to include the projectID field
when using Workload Identity in GKE. Builds upon the foundation from
external-secrets#4575, external-secrets#4622, and external-secrets#5208 which made cluster identity parameters optional.

Problem:
While cluster identity parameters (ClusterLocation, ClusterName,
ClusterProjectID) became optional via metadata server lookup, the main
projectID field (specifying where secrets are stored) remained required.
This forced users to parameterize SecretStore configurations per-cluster,
preventing static GitOps deployments via Config Sync/Fleet in
multi-project environments.

Solution:
When projectID is omitted from SecretStore/ClusterSecretStore spec:
1. clusterProjectID() falls back to GCP metadata server
2. NewClient() populates gcpStore.ProjectID with detected value

This allows the operator to access secrets in the same project as the
GKE cluster without explicit configuration.

Use Cases:
- Portable SecretStore configs across multiple GCP projects
- Static bootstrap manifests via Config Sync without parameterization
- Eliminates cross-cluster network dependencies for private GKE clusters

Changes:
- provider.go: Add metadata server fallback in clusterProjectID()
- provider.go: Populate gcpStore.ProjectID from clusterProjectID when empty
- workload_identity_test.go: Add TestClusterProjectIDMetadataFallback
- docs: Document projectID auto-detection feature with examples

Note: projectID remains required when using static service account
credentials, running outside GKE, or accessing secrets in a different
project than the GKE cluster.

Signed-off-by: Patrick Martin <patmarti@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@moolen moolen moolen approved these changes

@knelasevero knelasevero Awaiting requested review from knelasevero knelasevero was automatically assigned from external-secrets/maintainers

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

CRDs need updating to support recent change in gcpsm auth provider

2 participants

@gusfcarvalho @moolen