Emit security configuration by default

[easwars]

No description provided.

[easwars]

@sanjaypujare

[easwars]

@ejona86
This is in preparation for the upcoming security GA release. We need to be in a position to cut the bootstrap generator release when required. Making this change will ensure that we have test coverage with this change before cutting the release.
Thanks.

[ejona86]

@sanjaypujare, can you confirm this feature is ready to be enabled by default?

[sanjaypujare]

@sanjaypujare, can you confirm this feature is ready to be enabled by default?

Yes. We have been running security in our staging environment for the past 3-4 months with the flag enabled. The plan is to enable security by default and test the bootstrap generator (from this commit) in all of our staging environments before making a formal release with that change.

[ejona86]

Should this wait until grpc/proposal#243 is merged?

[easwars]

Should this wait until grpc/proposal#243 is merged?

Hmm ... I don't expect anything to change here based on any changes in the gRFC. So, I'm ok going forward with this, and that way we can get the staging tests to use the new version, and we can be more ready to push the new release out when time comes.

[ejona86]

that way we can get the staging tests to use the new version, and we can be more ready to push the new release out when time comes.

That saves ~1 day of calendar time. I think it is weird to enable any flags for security in any language until the gRFC is merged or we agree it is "safe" to do so (for example, if things are held up for unrelated reasons).

I'm a bit concerned about https://github.com/grpc/proposal/pull/243/files/414e01c80dff3ed2ff57a7be582d4e73ed659fd2 and some related SPIFFE trust domain conversations (alluded to at envoyproxy/envoy#17201 (comment)). That said, given how late this discussion is happening we'll have serious trouble making any substantial changes. But I still see limited benefit to rushing this piece.

[ejona86]

Let's wait.

[sanjaypujare]

Let's wait.

Is there another way to test out this change in a staging environment? Note that the plan was to just commit the change but not build a binary (but use the commit-triggered build in staging)

[ejona86]

It is a flag. Pass --include-psm-security-experimental=true

[sanjaypujare]

It is a flag. Pass --include-psm-security-experimental=true

Yes, the idea was to not use the flag and have the security config be present by default and test it everywhere possible.

[easwars]

Resolved merge conflicts. PTAL @ejona86