Network template to support project parameter as one of the configurable elements

[vital4ik]

Currently there is no way to specify the project in the template or the yaml. when using the template, networks are created in the DM creator project instead of the project that is being created. the option to provide the project as a parameter is not really working when this template is in a sequence of other templates used to create and configure brand new project.

[ocsig]

Thank you for your feedback!

• This repo is splitting to two, the CloudFoundation Toolkit templates are moving here: https://github.com/GoogleCloudPlatform/cloud-foundation-toolkit/tree/cft-dm-dev/dm/templates

(Please note, this is the dm-cft-dev branch, which is currently under development. This should be promoted to master within weeks.)

• The dm-cft-dev branch contains a large refactoring, incudling features such as cross project deployment support, versioning, gcp-type and latest API version support

• The CFT CLI ( currenty python implementation and future GO implementation) is supporting cross deployment referencing.

Feel free to let me know if you have any further question.

[vital4ik]

Hi, my current issue is that when i create a project and then in the sample template i try to create a VPC, there is no way for me to control what project the VPC is being created in. I cant use --project=project with the CFT command as all values including constructing the project name are dynamic within one global template that sets everything up in the project after its created. other templates like iam_member support providing project name so it is created in the correct project but network template does not seem to have the concept of the project.

[vital4ik]

here is an example of what I am trying to achieve: `{%- set id_prefix = "{}-{}-{}".format( properties.get("company", "NA") , properties.get("name", "NA") , properties.get("env", "NA") ) -%} {%- set location_prefix1 = "{}-{}".format( id_prefix , properties.get("region1", "NA") ) -%} {%- set location_prefix2 = "{}-{}".format( id_prefix , properties.get("region2", "NA") ) -%} resources:

• name: {{ id_prefix }}-pr type: project_template.jinja properties: name: {{ id_prefix }}-pr billingAccountId: xxxxxxx parentid: xxxxxxx removeDefaultVPC: true sharedVPChost: true concurrentApiActivation: true apis:
  • compute.googleapis.com
  • cloudresourcemanager.googleapis.com
  • deploymentmanager.googleapis.com
  • pubsub.googleapis.com
  • storage-component.googleapis.com
  • monitoring.googleapis.com
  • logging.googleapis.com
  • container.googleapis.com
  • containerregistry.googleapis.com
  • containeranalysis.googleapis.com
  • containerscanning.googleapis.com
  • iap.googleapis.com

    - redis.googleapis.com

  • servicemanagement.googleapis.com
  • servicenetworking.googleapis.com
  • serviceusage.googleapis.com

    - sql-component.googleapis.com

  • websecurityscanner.googleapis.com
  • cloudapis.googleapis.com
  • binaryauthorization.googleapis.com
  • endpoints.googleapis.com

    - clouddebugger.googleapis.com

  • cloudkms.googleapis.com
  • iamcredentials.googleapis.com
  • iam.googleapis.com serviceaccounts:
  • accountId: xxxxxxxx displayName: xxxxxxx Service Account roles:
    • roles/storage.admin
    • roles/logging.logWriter
    • roles/viewer
  • accountId: xxxxxxx-sa displayName: xxxxx Service Account roles:
    • roles/container.admin
    • roles/logging.logWriter
    • roles/viewer groups:
  • name: group@domain roles:
    • roles/viewer
• name: {{ id_prefix }}-iamadd type: iam_member.jinja properties: name: {{ id_prefix }}-pr projectId: {{ id_prefix }}-pr roles:
  • role: roles/editor members:
    • user:user@domain.com
    • serviceAccount:sa-xxxx@xxxxxxx.iam.gserviceaccount.com
  • role: roles/viewer members:
    • domain:xxxxx.com
    • group:xxxxx@domain.com
  • role: roles/owner members:
    • serviceAccount:1234567@cloudservices.gserviceaccount.com
  • role: roles/resourcemanager.organizationAdmin members:
    • serviceAccount:1234567@cloudservices.gserviceaccount.com
• name: {{ id_prefix }}-vpc type: network.py properties: projectId: {{ id_prefix }}-pr name: {{ id_prefix }}-vpc autoCreateSubnetworks: false subnetworks:
  • name: {{ location_prefix1 }}-subnet-1 region: {{ properties["region1"] }} ipCidrRange: 10.0.0.0/23 privateIpGoogleAccess: true enableFlowLogs: true

    secondaryIpRanges:

    - rangeName: secondary-range-1

    ipCidrRange: 10.0.4.0/24

    - rangeName: secondary-range-2

    ipCidrRange: 10.0.5.0/24

  • name: {{ location_prefix2 }}-subnet-2 region: {{ properties["region2"] }} ipCidrRange: 192.168.0.0/24 privateIpGoogleAccess: true enableFlowLogs: true` right now the jinja has project creation, IAM roles and network. IAM roles respect the project that just got created but network.py does not support concept of the project so network components are created in the DM creator project instead of the project being created.

[ocsig]

I highly recommend to create resources in deployments which are in the same project where the resource itself. I see benefits of avoiding cross project deployments. One advantage is you can use --project (or the CTF cli project property in the yaml.) It also gives you greater separation of duties via IAM.

If you really wish to stick to cross project deployments, the dev branch implements it for most of the resources: https://github.com/GoogleCloudPlatform/cloud-foundation-toolkit/tree/cft-dm-dev/dm/templates/network ( keep in mind, some templates like cloudFunctions does not support cross project deployments.)