xds/gcp_authn: implement GCP Authentication filter (gRFC A83).

[Pranjali-2501]

This PR implements the xDS GCP Authentication HTTP filter for gRPC-Go, as specified in gRFC A83.

The implementation provides a mechanism for attaching service account identity JWT tokens as gRPC call credentials on GCP, featuring a two-level caching strategy (filter-level cache of credentials objects and credential-level cache of tokens) to minimize latency and metadata server load.

RELEASE NOTES:

• xds: add support for the GCP Authentication HTTP Filter. It automatically fetches and attaches GCP Service Account Identity JWT tokens to outgoing RPCs. This feature is currently gated behind the GRPC_EXPERIMENTAL_XDS_GCP_AUTHENTICATION_FILTER environment variable.

[Pranjali-2501]

/gemini review

[codecov]

Codecov Report

❌ Patch coverage is 87.68116% with 17 lines in your changes missing coverage. Please review.
✅ Project coverage is 83.23%. Comparing base (11d0baf) to head (5513377).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
...ernal/xds/httpfilter/gcp_authn/gcp_authn_filter.go	90.90%	6 Missing and 4 partials ⚠️
internal/xds/xdsclient/xdsresource/metadata.go	68.18%	6 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #9119      +/-   ##
==========================================
- Coverage   83.24%   83.23%   -0.02%     
==========================================
  Files         419      420       +1     
  Lines       33884    34008     +124     
==========================================
+ Hits        28206    28305      +99     
- Misses       4258     4272      +14     
- Partials     1420     1431      +11     

Files with missing lines	Coverage Δ
internal/xds/balancer/clustermanager/picker.go	100.00% <100.00%> (ø)
internal/xds/httpfilter/extproc/ext_proc.go	76.52% <100.00%> (ø)
internal/xds/httpfilter/fault/fault.go	72.79% <100.00%> (ø)
internal/xds/httpfilter/httpfilter.go	87.50% <ø> (ø)
internal/xds/httpfilter/router/router.go	46.15% <100.00%> (ø)
internal/xds/resolver/xds_resolver.go	86.83% <100.00%> (ø)
internal/xds/xdsclient/xdsresource/metadata.go	70.58% <68.18%> (+0.31%)	⬆️
...ernal/xds/httpfilter/gcp_authn/gcp_authn_filter.go	90.90% <90.90%> (ø)

... and 34 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[gemini-code-assist]

Code Review

This pull request introduces GCP Service Account Identity credentials and a new xDS HTTP filter, gcp_authn, which attaches these credentials to outgoing RPCs using cluster metadata. The implementation features an LRU cache for credential management. Key review feedback points out critical bugs involving incorrect access paths for cluster metadata and security settings, which would cause nil pointer dereferences or compilation failures. Furthermore, the reviewer identified significant thread-safety issues in the cache resizing logic that could lead to data races. A minor suggestion was also made to declare the early expiry duration as a constant.

[easwars]

Still haven't looked at the last two tests in internal/xds/httpfilter/gcp_authn/gcp_authn_filter_e2e_test.go

[easwars]

I spent a little more time on the implementation of getOrCreate in the LRU. What I suggested (prioritizing simplicity over performance in high-concurrency environments) is not what we should ideally do. There are a couple of reasons:

• google.NewServiceAccountIdentityCredentials does file I/O. So, it does not make sense to block all RPCs on the gRPC channel when a credentials for one audience needs to be fetched.
• There will be a single instance of the filter for a gRPC channel and there would be multiple interceptors sharing the same cache. So, holding the lock for the slow path does not make sense.

But I also did not like the earlier approach where we had too many manual calls to Unlock. I suggest the following approach. Please read through and see if you like it and let me know if you see any issues with it.

• Use package singleflight. Add a singleflight.Group to the filter:

       // sf is used to deduplicate credential creation for the same audience.
       sf singleflight.Group

• Add a method to the lruCache that handles the fast path and takes of deferring the unlock:

// getExisting retrieves the PerRPCCredentials for a specified audience if it
// already exists in the cache. It updates the access order in the LRU list.
//
// The boolean return value indicates if an entry was found in the cache.
func (c *lruCache) getExisting(audience string) (credentials.PerRPCCredentials, error, bool) {
       c.mu.Lock()
       defer c.mu.Unlock()

       if entry, ok := c.cache[audience]; ok {
               c.lruList.MoveToFront(entry.el)
               return entry.creds, nil, true
       }
       return nil, nil, false
}

• Modify getOrCreate as follows:

func (c *lruCache) getOrCreate(ctx context.Context, audience string) (credentials.PerRPCCredentials, error) {
	if creds, err, ok := c.getExisting(audience); ok {
		return creds, err
	}

	val, err, _ := c.sf.Do(audience, func() (interface{}, error) {
		return google.NewServiceAccountIdentityCredentials(ctx, audience)
	})
	if err != nil {
		return nil, err
	}
	creds := val.(credentials.PerRPCCredentials)

	c.mu.Lock()
	defer c.mu.Unlock()

	if entry, ok := c.cache[audience]; ok {
		c.lruList.MoveToFront(entry.el)
		return entry.creds, nil
	}

	if uint64(len(c.cache)) >= c.cacheSize {
		c.removeOldestLocked()
	}
	el := c.lruList.PushFront(audience)
	c.cache[audience] = &cacheEntry{creds: creds, el: el}
	return creds, nil
}

[Pranjali-2501]

I have changed getORCreate method in a little different way from what you have suggested, PTAL.

[easwars]

Minor nit:

Suggested change

	e := c.lruList.PushFront(audience)
	c.cache[audience] = &cacheEntry{creds: creds, elem: e}
	c.cache[audience] = &cacheEntry{
	creds: creds,
	elem: c.lruList.PushFront(audience),
	}

[easwars]

Nit: if interceptor.cache == nil, then this line will panic when you try to access interceptor.cache.cacheSize.

[easwars]

Same here.

[easwars]

Nit: s/wantCacheSize/wantCacheSizes/

Alternatively, you could define cfg1, cfg2 and wantCacheSize1 and wantCacheSize2.

[Pranjali-2501]

Replaced wantCacheSize with wantCacheSizes.

I would like to keep it as slice of sizes and cfgs.

[easwars]

LGTM, modulo minor nits

[easwars]

Nit: Expand this comment to say that the filtername is used as the key in the cluster metadata to look up the audience value for the cluster to which the RPC is destined to.

[easwars]

Nit: You can get rid of the local m here.

[easwars]

Nit: what does promotion mean here?

[Pranjali-2501]

promotion means moving the existing entry to the starting of the list, marking it as most recently used element.

Updated the comment to "cache maps audience keys to their corresponding cacheEntry pointers, allowing O(1) lookups and updates in the LRU list." to make more sense

[easwars]

Nit: It might be useful to print all errors here instead of just the first one. So, consider using t.Errorf and if we do that we would also get the added benefit of seeing the requestCount value below.