Add filtering-proxy-psc blueprint

[kunzese]

This PR adds a new variation of the filtering-proxy blueprint in which the shared VPC is replaced by isolated VPCs and the proxy service is published and consumed via the Private Service Connect.

FYI @gaspar-chilingarov

[ludoo]

Thanks for this submission!

Most of our blueprints try to minimize requirements by allowing reuse of a preexisting project, VPC, etc. as many users only have a project available for testing.

Do you think a folder is necessary? Can we make project creation optional like in most other blueprints, and allow reuse of an existing VPC for clients? There are several examples here on how to do that.

[gaspar-chilingarov]

I would suggest that we move example of how the environment should be set up (folder + org.policy for external IPs) into separate example-environment.tf (or something similarly named), so that user can remove such file if they want to or move into some other part of the TF codebase.

Same with creating folter 'netops' - most probably customer already has it, so we can just leave it in the example and user wants they can replace local object/variable that points to the folder.

About using connection_preference = "ACCEPT_AUTOMATIC" - we may want to warn users in the documentation that this is potential security problem (any project in GCP can connect to such provider) and they need to use MANUAL mode and provide list of the projects (most probably integrating this with the creation of the Shared VPC hosts/standalone projects in Project Factory).

[ludoo]

I would suggest that we move example of how the environment should be set up (folder + org.policy for external IPs) into separate example-environment.tf (or something similarly named), so that user can remove such file if they want to or move into some other part of the TF codebase.

I disagree: blueprints are limited examples and don't prescribe "how the environment should look like", which is a foundational design topic. In this case, the example shows a proxy via PSC, there's no prescriptive guidance that would involve folders or specific project layouts needed.

This repository has a very specific approach, and examples that are not reflecting it will not be accepted.

[ludoo]

One more thing: we also strongly discourage submodules and nested patterns. This is all detailed clearly in our contributing guidelines. What's the rationale for having a submodule here?

[kunzese]

@ludoo done - everything is now in the same project, which can already exist or will be created if not
@gaspar-chilingarov - connection_preference = "ACCEPT_AUTOMATIC" has been changed to "ACCEPT_MANUAL"

[ludoo]

Let me rephrase the comments above in a more productive way: what is the bare minimum design and resources that would allow showing this feature?

[kunzese]

One more thing: we also strongly discourage submodules and nested patterns. This is all detailed clearly in our contributing guidelines. What's the rationale for having a submodule here?

This has been taken from the psc-hybrid blueprint, but i can change that as well.

[kunzese]

@ludoo submodule removed

[gaspar-chilingarov]

We may need 2 projects to showcase the feature

• first where the squid + PSC producer is installed and
• second proejct - with the VPC with PSC endpoint is created and VM with proxy configuration is installed.

How should be go about it? Have 2 different directories with examples of proxy and example of consumer?

edit: I see that this is implemented in the same file. Most probably splitting main.tf into 2 files would help :)

[kunzese]

We may need 2 projects to showcase the feature

• first where the squid + PSC producer is installed and
• second proejct - with the VPC with PSC endpoint is created and VM with proxy configuration is installed.

How should be go about it? Have 2 different directories with examples of proxy and example of consumer?

edit: I see that this is implemented in the same file. Most probably splitting main.tf into 2 files would help :)

Actually we can do everything in one project with separate VPCs.

[ludoo]

This is really nice, thanks! :)

A couple minor additions if you still have the energy

• variables and outputs should be sorted alphabetically, tests will fail if they aren't
• you might want to add links to the top-level/blueprint/section READMEs to make this discoverable

I am also adding you to the repo users, so you will be able to run tests, merge once all checks pass, and in the future use local branches for PRs.

[ludoo]

@kunzese feel free to merge whenever you're ready :)