Implement upstream authority plugin for GCP #2172

dragcp · 2021-03-25T20:11:07Z

Signed-off-by: ramand.dragcp [email protected]

Pull Request check list

[*] Commit conforms to CONTRIBUTING.md?
[*] Proper tests/regressions included?
[*] Documentation updated?

Affected functionality
Adds a new plugin for GCP Certificate Authority Service backed upstream authority

Description of change
Thank you for reviewing the PR #2039 by @Jonpez2. I am continuing that PR here. I believe I have incorporated all of the feedback

A few notes:

Changes to go.sum and go.mod happened automatically as part of "make build"
We pick all the CAs in GCP CAS that are in enabled state and also matches the specified label key/value pair. The one with the earliest expiration is used to create and sign intermediate CAs
I have tried to included relevant documentation links for most of the APIs and types of GCP CAS.

Which issue this PR fixes

azdagron · 2021-03-25T20:14:08Z

Thank you for pushing the feature forward, @dragcp. I'll close out #2039 in favor of this.

amartinezfayo

Thank you @dragcp! I have some initial comments/suggestions.

doc/plugin_server_upstreamauthority_gcp_cas.md

doc/spire_server.md

amartinezfayo · 2021-03-26T12:37:46Z

pkg/server/plugin/upstreamauthority/gcpcas/gcpcas.go

+	}
+	if len(allCertRoots) == 0 {
+		rootSpec := config.RootSpec
+		return nil, makeError(codes.Internal, "no certificate authorities found with label pair %q:%q", rootSpec.LabelKey, rootSpec.LabelValue)


Returning codes.InvalidArgument feels more appropriate to me here, since the error is due to the current configuration / state rather than an internal plugin failure.

amartinezfayo · 2021-03-26T13:19:46Z

doc/plugin_server_upstreamauthority_gcp_cas.md

+| Configuration                 | Description                                                       |
+| ----------------------------- | ----------------------------------------------------------------- |
+| root_cert_spec.project_name   | Project in GCP that has the root CA certificate                   |
+| root_cert_spec.region_name    | The name of the region within GCP                                 |


Looks like this is implemented without the root_cert_spec. prefix, which I think that is a good choice.

Suggested change

| root_cert_spec.region_name | The name of the region within GCP |

| region_name | The name of the region within GCP |

Sorry @amartinezfayo

This configuration table is correct. We do need root_cert_spec. It is the "sample configuration" section which is incorrect. The correct version is there in gcpcas.go as well as in gcpcas_test.go

I will correct and update the sample configuration in this doc to be:

upstreamAuthority "gcp_cas" { plugin_data { root_cert_spec { project_name = "MyProject" region_name = "us-central1" label_key = "myapp-identity-root" label_value = "true" } trust_bundle_cert_spec = [ { project_name = "DifferentProject" region_name = "us-east1" label_key = "differentapp-identity-root" label_value = "true" } ] }

With that being the case, is this Configuration table reasonable? Or is there a better way to denote / describe it?

I see now that there is a hierarchy, I missed that. I think that it's good to have the table but maybe split them in two: one for root_cert_spec and the other one for trust_bundle_cert_spec configs, and make it explicit. That way we can avoid to have the prefix notation that may be confusing.
Having a configuration example in addition to that is also good IMO.

Thank you

I will incorporate all of your feedback, squash, rebase and repush

If you wouldn't mind just pushing new commits on top, it's easier to see the diff of what has changed that way (reduces review burden). A rebase and squash at the end after it has all been sorted out would be great.

Pushing new commits on top is easier for me. I was under the wrong impression that squash and rebase was necessary

Let me stop squashing

amartinezfayo · 2021-03-26T13:20:41Z

doc/plugin_server_upstreamauthority_gcp_cas.md

+| ----------------------------- | ----------------------------------------------------------------- |
+| root_cert_spec.project_name   | Project in GCP that has the root CA certificate                   |
+| root_cert_spec.region_name    | The name of the region within GCP                                 |
+| root_cert_spec.label_key      | Label key - value pair is used to filter and select the relevant certificate  |


Looks like this is implemented without the root_cert_spec. prefix, which I think that is a good choice.

Suggested change

| root_cert_spec.label_key | Label key - value pair is used to filter and select the relevant certificate |

| label_key | Label key - value pair is used to filter and select the relevant certificate |

amartinezfayo · 2021-03-26T13:21:01Z

doc/plugin_server_upstreamauthority_gcp_cas.md

+| root_cert_spec.project_name   | Project in GCP that has the root CA certificate                   |
+| root_cert_spec.region_name    | The name of the region within GCP                                 |
+| root_cert_spec.label_key      | Label key - value pair is used to filter and select the relevant certificate  |
+| root_cert_spec.label_value    | Label key - value pair is used to filter and select the relevant certificate  |


Looks like this is implemented without the root_cert_spec. prefix, which I think that is a good choice.

Suggested change

| root_cert_spec.label_value | Label key - value pair is used to filter and select the relevant certificate |

| label_value | Label key - value pair is used to filter and select the relevant certificate |

amartinezfayo · 2021-03-26T13:22:25Z

doc/plugin_server_upstreamauthority_gcp_cas.md

+| trusted_root_spec             | ( Optional ) Array of entries containing project_name, region_name, label_key and label_value as described in root_cert_spec  |
+
+
+##Sample configuration:


The conf/server/server_full.conf file should be updated with an example configuration also.

I have added it to server_full_conf

pkg/server/plugin/upstreamauthority/gcpcas/gcpcas.go

azdagron

Thanks for putting the final touches on this @dragcp. Things are looking pretty good. I had one big question around the inclusion of intermediates being included in the trust bundle that don't terminate with a root in the trust bundle that I think we need to figure out.

Also, it looks like the use of cloud.google.com/go has pulled in a bump to the gRPC and protobuf dependencies. I think it would be best if those dependencies were bumped in their own PR (that includes the changes to all of the regenerated code). I'm happy to put that PR up if you'd rather.

azdagron · 2021-03-26T16:58:35Z

doc/plugin_server_upstreamauthority_gcp_cas.md

+to generate intermediate signing certificates for SPIRE Server.
+
+# Considerations
+This plugin relies on GCP Certificate Authority Service which is currently in Beta. So please do not use this plugin in production


If the plugin is not ready for production, because GCP CAS is not ready for production, we may consider logging a warning during the Configure() call.

I have added a warning message

doc/plugin_server_upstreamauthority_gcp_cas.md

azdagron · 2021-03-26T17:02:34Z

pkg/server/plugin/upstreamauthority/gcpcas/gcpcas.go

+	LoadCertificateAuthorities(ctx context.Context, spec CertificateAuthoritySpec) ([]*privatecapb.CertificateAuthority, error)
+}
+
+type gcpCAClient struct {


nit: we typically group unexported structs, methods, and functions below exported ones

I have switched the order

pkg/server/plugin/upstreamauthority/gcpcas/gcpcas.go

azdagron · 2021-03-26T17:14:19Z

pkg/server/plugin/upstreamauthority/gcpcas/gcpcas.go

+	}
+
+	// Swap out the current configuration with the new configuration
+	p.setConfig(config)


We should be validating the configuration before setting (or replacing) here. At a minimum we need to ensure the required fields are present and where it is possible, ensure the values are within the proper range or have the proper shape.

I am validating it. And added a few tests for that

azdagron · 2021-03-26T17:15:48Z

pkg/server/plugin/upstreamauthority/gcpcas/gcpcas.go

+	p.log.Debug("Request to GCP_CAS to mint new X509")
+	csrParsed, err := x509.ParseCertificateRequest(csr)
+	if err != nil {
+		return nil, makeError(codes.Internal, "unable to parse CSR: %v", err)


Probably want InvalidArgument here since this would imply SPIRE gave the plugin a bad value.

pkg/server/plugin/upstreamauthority/gcpcas/gcpcas.go

azdagron · 2021-03-26T17:23:59Z

pkg/server/plugin/upstreamauthority/gcpcas/gcpcas.go

+	// trust bundle spec
+	rootBundle := make([]*x509.Certificate, 0, len(trustBundle))
+	for _, c := range trustBundle {
+		// Note. We are intentionally retrieving the immediate CAs from the GCP CAS that


Does this mean that we can end up with intermediates in the trust bundle that don't chain up to a root also in the trust bundle? This can be very problematic for downstream software, which does not always verify such chains successfully by default (e.g. OpenSSL).

The scenario that I have in mind is:

Lets say that there are three departments of the same organization in google cloud project. The three departments have their own CA - say caX, caY and caZ respectively. And they might all have the same root CA - caM

If each department is their own trust domain ( say domain X, Y and Z ) and trust domain X and Y needs to trust each other but not domain Z

If we have caM in the trust bundle, then wouldn't it allow any department to accept any SVID generated from any department?

I was hoping that if we can tag with appropriate labels, then the trust bundle will only contain caX and caY rather than caM

Or is it a precondition that each trust domain should have an exclusive root CA? That would also eliminate the above problem

Outside of verification woes by stacks that use OpenSSL (and probably others), I think including intermediates in the trust bundle is dangerous. It makes it much easier to accidentally open up trust in unintended ways. In this case, what you REALLY trust is the root. Without some way of constraining that intermediate, its hard to anchor trust in it. What you don't want is workloads in two trust domains with intermediates in the trust bundle to accidentally trust each other because they got their hands on the root somewhere (say from the system pool) and included it in their verification chain. That opens up doors for one trust domain to impersonate workloads in the other trust domain.

Or is it a precondition that each trust domain should have an exclusive root CA? That would also eliminate the above problem

It's not strictly required, but is strongly encouraged and generally assumed

I agree with everything @azdagron said. SPIRE used to include intermediates in the bundle (and exclude the real roots) to address the use case you're describing, but we found that in practice it didn't work well, wasn't very safe, and led to a lot of confusion. Removing certs from the bundle is hard from a compat standpoint - adding them is of course easy :)

I think people that find themselves in the circumstance you describe... which I might summarize as "We all have to have intermediates that share a root due to corporate policy, but we don't really trust each other" ... should lean on name constraints to solve their problems.

Makes sense. Thank you. Switched to root rather than intermediate

azdagron · 2021-03-26T17:26:32Z

pkg/server/plugin/upstreamauthority/gcpcas/gcpcas_test.go

+	return allCerts, nil
+}
+
+func TestGcpCAS(t *testing.T) {


nit: prefer the test methods to be at the top and all of the scaffolding (e.g. fakeClient) to be below. This follows our general guidance of exported methods/types sorting before unexported methods/types.

dragcp · 2021-03-26T17:56:31Z

Also, it looks like the use of cloud.google.com/go has pulled in a bump to the gRPC and protobuf dependencies. I think it would be best if those dependencies were bumped in their own PR (that includes the changes to all of the regenerated code). I'm happy to put that PR up if you'd rather.

Do I need to do "go get cloud.google.com/go", "make all" and "make generate-check" and commit whatever has changed to a new PR?

azdagron · 2021-03-26T18:06:30Z

We can scope it more finely to just gRPC and protobuf with:

$ go get google.golang.org/[email protected]

$ go get google.golang.org/protobuf/[email protected]

$ go mod tidy

$ make generate

dragcp · 2021-03-26T18:50:13Z

Thank you. I have raised a PR at #2175 to upgrade the dependencies separately

azdagron · 2021-03-26T19:11:58Z

#2175 has been merged.

azdagron · 2021-03-27T18:05:04Z

I just merged a big change related to UpstreamAuthority plugin interfaces that will cause a some conflicts here. If you don't mind, I can merge in master and push a commit to fix it all up. Happy to clean up my mess. Please let me know if you are ok with that.

MarcosDY · 2021-03-29T14:14:25Z

pkg/server/plugin/upstreamauthority/gcpcas/gcpcas.go

+)
+
+func makeError(code codes.Code, format string, args ...interface{}) error {
+	return status.Errorf(code, "GCPCAS: "+format, args...)


error must never start with uppercase, this may be:
return status.Errorf(code, "gcp_cas: "+format, args...)

MarcosDY · 2021-03-29T15:45:20Z

pkg/server/plugin/upstreamauthority/gcpcas/gcpcas.go

+	TrustBundleSpecs []CertificateAuthoritySpec `hcl:"trust_bundle_cert_spec,block"`
+}
+
+type CAClient interface {


I'm not sure about this interface, with this approach we are not able to tests our filters that are inside LoadCertificateAuthorities,
what do you think about our LoadCerticates only calls gcp but filter and maybe sort is done post loading?

I have separated them out and updated test case to cover it

MarcosDY · 2021-03-29T16:35:23Z

pkg/server/plugin/upstreamauthority/gcpcas/gcpcas_test.go

+)
+
+func generateCert(cn string, issuer *x509.Certificate, issuerKey crypto.PrivateKey) (*x509.Certificate, crypto.PrivateKey, error) {
+	priv, err := ecdsa.GenerateKey(elliptic.P256(), rand.Reader)


why not to use keys we have on fixture? https://github.com/spiffe/spire/blob/master/test/testkey/new.go#L41

I am using it now

MarcosDY · 2021-03-29T16:49:09Z

pkg/server/plugin/upstreamauthority/gcpcas/gcpcas_test.go

+    `})
+	require.NoError(t, err)
+
+	priv, err := ecdsa.GenerateKey(elliptic.P256(), rand.Reader)


may we use fixture here?

dragcp · 2021-03-29T21:10:56Z

I just merged a big change related to UpstreamAuthority plugin interfaces that will cause a some conflicts here. If you don't mind, I can merge in master and push a commit to fix it all up. Happy to clean up my mess. Please let me know if you are ok with that.

Sorry @azdagron. I did not notice your comment till now. Thank you. Please feel free to do so

I have addressed the review comments locally. After you push the changes, I will commit on top of that

Signed-off-by: ramand.dragcp <[email protected]>

Co-authored-by: Agustín Martínez Fayó <[email protected]> Signed-off-by: ramand.dragcp <[email protected]>

azdagron · 2021-03-30T20:54:39Z

Thanks, @dragcp. I'll take a look.

azdagron · 2021-03-30T21:24:34Z

conf/server/server_full.conf

+    #             project_name = ""
+    #             region_name = ""


wrong keys here

azdagron · 2021-03-30T21:24:40Z

conf/server/server_full.conf

+    #             project_name = ""
+    #             region_name = ""


wrong keys here

azdagron · 2021-03-30T21:28:39Z

pkg/server/plugin/upstreamauthority/gcpcas/gcpcas.go

+	// Also pick up if there any additional trust CAs (as per label in plugin config)
+	for _, spec := range config.TrustBundleSpecs {
+		trustBundleCerts, err := pcaClient.LoadCertificateAuthorities(ctx, spec)
+		trustBundleCerts = filterOutNonEnabledCAs(trustBundleCerts)


nit: can you move this after the error check? in general, using the result without checking the error first is a code smell.

Maybe we do the Load+Filter step in a helper that is shared for both the root spec and trust bundle spec loading.

func loadCertificateAuthorities(ctx context.Context, caClient CAClient, spec CertificateAuthoritySpec) ([]*privatecapb.CertificateAuthority, error) { cas, err := caClient.LoadCertificateAuthorities(ctx, spec) if err != nil { // handle error } return filterOutNonEnabledCAs(cas), nil }

azdagron · 2021-03-30T23:08:21Z

I've given it a lot of thought. I don't think we want the functionality provided by trust_bundle_spec. It makes it too easy to do the wrong thing. When something is included in the bundle, from the perspective of the workload, other participants in the trust domain, and even those federating with that trust domain, that root is considered authoritative for that trust domain.

In other words, the trust bundle is not the appropriate way to distribute other roots to workloads. There are other mechanisms for that.

The trust_bundle_spec is used to grab roots for other CAs presumably unrelated to the signing of SPIRE intermediates. I can't think of a good use case where these bundles should be considered authoritative for the trust domain but aren't actually used to sign SPIRE intermediates.

Maybe I'm missing something here?

azdagron · 2021-03-31T00:11:10Z

I've just merged #2180. Consequently, you'll need to touch up the import for the upstreamauthority definitions.

Old import:
upstreamauthorityv0 "github.com/spiffe/spire/proto/spire/server/upstreamauthority/v0"
New import:
upstreamauthorityv0 "github.com/spiffe/spire/proto/spire/plugin/server/upstreamauthority/v0"

If you'd rather me touch it up and push a commit, I'm happy to oblige. Just let me know.

dragcp · 2021-03-31T02:23:56Z

I've given it a lot of thought. I don't think we want the functionality provided by trust_bundle_spec. It makes it too easy to do the wrong thing. When something is included in the bundle, from the perspective of the workload, other participants in the trust domain, and even those federating with that trust domain, that root is considered authoritative for that trust domain.

In other words, the trust bundle is not the appropriate way to distribute other roots to workloads. There are other mechanisms for that.

The trust_bundle_spec is used to grab roots for other CAs presumably unrelated to the signing of SPIRE intermediates. I can't think of a good use case where these bundles should be considered authoritative for the trust domain but aren't actually used to sign SPIRE intermediates.

Maybe I'm missing something here?

Wouldn't it be the same as "supplemental_bundle_path" in aws_pca plugin? The only difference is that this is coming from GCP CAS instead of local disk
https://github.com/spiffe/spire/blob/master/doc/plugin_server_upstreamauthority_aws_pca.md

The associated ticket has a use case listed for two sets of root CA in a single trust domain where we sign with one set but the trust bundle has both:
#1573

dragcp · 2021-03-31T02:25:02Z

I've just merged #2180. Consequently, you'll need to touch up the import for the upstreamauthority definitions.

Old import:
upstreamauthorityv0 "github.com/spiffe/spire/proto/spire/server/upstreamauthority/v0"
New import:
upstreamauthorityv0 "github.com/spiffe/spire/proto/spire/plugin/server/upstreamauthority/v0"

If you'd rather me touch it up and push a commit, I'm happy to oblige. Just let me know.

Thank you. I will update it as part of my fixes

azdagron · 2021-03-31T16:47:03Z

Can you help me understand maybe a concrete use case that requires the functionality provided by trust bundle spec? I've dug into the previous PR when it was introduced and I'm not convinced there wasn't a misunderstanding there on how the trust bundle is built and maintained through the preparation and activation intervals, based on the responses from the UpstreamAuthority.

I'm not opposed to it per-se, I just need to understand the concrete scenario it is solving. If the use case is theoretical, I'd probably advocate for leaving it out for now. It's much easier to add something like this later than it is to deprecate it out if it turns out to be the wrong thing.

dragcp · 2021-03-31T17:47:05Z

We have an application composed of multiple services talking to each other. We might also have the same service running concurrently with different versions of the software ( say RC vs Prod ). Any service can call any other service including RC version calling Production version. We want each service to authorize the call based on which service is calling and whether that service is running non-prod version or prod version

We could model this as single trust domain. There are a set of root CAs for prod and set of root CAs for non-prod. Then we can have a set of spire servers that sign with only non-prod CAs and another set of spire servers which sign only with prod CAs. The trust bundle in all cases will contain both the prod and non-prod root CAs.

In this case, we will have two sets of information. (1) the SPIFFE Id identifies the workload. Say spiffe://mytrustdomain.org/serviceA. (2) the rootCA can tell us whether it was a prod version of the software or non-prod version of the software

So after a service to service call has performed mTLS for authentication, it can traverse the CA chain to identify whether it was signed by prod CA or non-prod CA and use that information to take authorization decision

Extending it further, we could have few more intermediate certificates with parent as non-prod CA for finer grained authorization ( than just a binary prod vs non-prod )

azdagron · 2021-03-31T18:13:28Z

Thank you for taking the time to provide that use case. Some questions:

Then we can have a set of spire servers that sign with only non-prod CAs and another set of spire servers which sign only with prod CAs

Do these SPIRE servers share a database (i.e. configured to use the same datastore)? If they have a shared database, then there is no need for each SPIRE server to return anything but the exact upstream root that signed its intermediate, since upstream roots are appended by each SPIRE server to the trust bundle. The datastore layer is the canonical source of the trust bundle for the trust domain. The roots returned from the UpstreamAuthority plugin are _not _ treated as the definitive set of authorities, but are instead appended to the existing roots present in bundle.

In this case, we will have two sets of information. (1) the SPIFFE Id identifies the workload ... (2) the rootCA can tell us whether it was a prod version of the software or non-prod version of the software

An alternative here would be to model the prod and non-prod services as having distinct SPIFFE IDs (e.g. spiffe://mytrustdomain.org/prod/serviceA v.s. spiffe://mytrustdomain.org/prod/serviceB). One complication of using the rootCA as an indicator of whether it is prod or non-prod is that each 1) workload needs to understand what the set of prod CAs is, and that understanding needs to survive CA rotation. 2) each workload needs to perform this awkward inspection of the root CA to determine prod v.s. non-prod.

azdagron · 2021-03-31T18:27:26Z

Furthermore, let's say you decide later on that you need to federate with other trust domains. Now you've likely pushed this prod/non-prod authorization semantic onto the other trust domain.

dragcp · 2021-03-31T21:26:55Z

Thank you

Let me discuss this with @Jonpez2 and get back to you tomorrow

azdagron · 2021-03-31T21:29:30Z

Awesome. I appreciate your willingness to work through these things. We're very excited about this plugin.

dragcp · 2021-03-31T21:53:53Z

Could you please help with one data point:

Is there any functional difference between two different spiffe servers running with isolated independent databases ( say sqllite ) vs a single shared database?

Is it that:
If the upstream authority plugins on two different servers are using two different root CAs and only the signing CA's root is returned as "upstreamX509Roots", then the trust bundle received by different workloads will not have both the CAs?

azdagron · 2021-03-31T22:03:16Z

Assuming each server has an independent CA, whether self-signed or a distinct upstream CA, then these are effectively two trust domains that happen to share the same name.

That's one difference. There are others, like each server will have its own set of registration entries, view of attested agents, etc.

dragcp · 2021-03-31T22:11:31Z

Thank you

azdagron · 2021-04-01T14:16:24Z

Another alternative: use a distinct trust domain for prod v.s. non-prod and federate the two.

Signed-off-by: ramand.dragcp <[email protected]>

dragcp · 2021-04-01T15:28:19Z

Thank you for all the suggestions. I have dropped trust_bundle_cert_spec and also merged in from the master.

azdagron

Thank you for this, @dragcp and @Jonpez2!

Implement upstream authority plugin for GCP Signed-off-by: Andrew Harding <[email protected]>

dragcp requested review from amartinezfayo, APTy, azdagron, evan2645 and rturner3 as code owners March 25, 2021 20:11

dragcp mentioned this pull request Mar 25, 2021

Implement an Upstream Authority backed by a GCP Certificate Authority #2039

Closed

3 tasks

dragcp force-pushed the gcpcasv2 branch from 3cdba82 to 92300ae Compare March 26, 2021 13:57

amartinezfayo reviewed Mar 26, 2021

View reviewed changes

azdagron reviewed Mar 26, 2021

View reviewed changes

dragcp mentioned this pull request Mar 26, 2021

Update grpc to v1.36.0 and proto to v1.26.0 #2175

Merged

2 tasks

MarcosDY reviewed Mar 29, 2021

View reviewed changes

dragcp and others added 2 commits March 30, 2021 17:30

Implement upstream authority plugin for GCP

f74045b

Signed-off-by: ramand.dragcp <[email protected]>

Incorporate PR feedback

6d6665c

Co-authored-by: Agustín Martínez Fayó <[email protected]> Signed-off-by: ramand.dragcp <[email protected]>

dragcp force-pushed the gcpcasv2 branch from ee1d176 to 6d6665c Compare March 30, 2021 18:35

dragcp requested a review from azdagron March 30, 2021 20:51

azdagron reviewed Mar 30, 2021

View reviewed changes

dragcp added 2 commits April 1, 2021 14:38

Merge remote-tracking branch 'upstream/master' into gcpcasv2

ff9f794

Signed-off-by: ramand.dragcp <[email protected]>

Drop trust_bundle_cert_spec option

e45cd46

Signed-off-by: ramand.dragcp <[email protected]>

azdagron approved these changes Apr 1, 2021

View reviewed changes

azdagron merged commit 48e1e55 into spiffe:master Apr 1, 2021

azdagron added a commit to azdagron/spire that referenced this pull request Apr 6, 2021

Merge pull request spiffe#2172 from dragcp/gcpcasv2

cf8d53e

Implement upstream authority plugin for GCP Signed-off-by: Andrew Harding <[email protected]>

azdagron added this to the 0.12.2 milestone Apr 6, 2021

	\| root_cert_spec.region_name \| The name of the region within GCP \|
	\| region_name \| The name of the region within GCP \|

	\| root_cert_spec.label_key \| Label key - value pair is used to filter and select the relevant certificate \|
	\| label_key \| Label key - value pair is used to filter and select the relevant certificate \|

	\| root_cert_spec.label_value \| Label key - value pair is used to filter and select the relevant certificate \|
	\| label_value \| Label key - value pair is used to filter and select the relevant certificate \|

		\| trusted_root_spec \| ( Optional ) Array of entries containing project_name, region_name, label_key and label_value as described in root_cert_spec \|


		##Sample configuration:

Implement upstream authority plugin for GCP #2172

Implement upstream authority plugin for GCP #2172

Conversation

dragcp commented Mar 25, 2021

azdagron commented Mar 25, 2021

amartinezfayo left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dragcp Mar 26, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

azdagron left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

azdagron Mar 26, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dragcp commented Mar 26, 2021

azdagron commented Mar 26, 2021

dragcp commented Mar 26, 2021

azdagron commented Mar 26, 2021

azdagron commented Mar 27, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dragcp commented Mar 29, 2021

azdagron commented Mar 30, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

azdagron commented Mar 30, 2021

azdagron commented Mar 31, 2021

dragcp commented Mar 31, 2021

dragcp commented Mar 31, 2021

azdagron commented Mar 31, 2021 • edited Loading

dragcp commented Mar 31, 2021

azdagron commented Mar 31, 2021 • edited Loading

azdagron commented Mar 31, 2021

dragcp commented Mar 31, 2021

azdagron commented Mar 31, 2021

dragcp commented Mar 31, 2021

azdagron commented Mar 31, 2021

dragcp commented Mar 31, 2021

azdagron commented Apr 1, 2021

dragcp commented Apr 1, 2021

azdagron left a comment

Choose a reason for hiding this comment

dragcp Mar 26, 2021 •

edited

Loading

azdagron Mar 26, 2021 •

edited

Loading

azdagron commented Mar 31, 2021 •

edited

Loading

azdagron commented Mar 31, 2021 •

edited

Loading