Terraform-provider-google: CIDR_BLOCKS dont function properly in master_authorized_networks_config for kubernetes

Created on 7 Nov 2018  ·  7Comments  ·  Source: hashicorp/terraform-provider-google


Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment
  • If an issue is assigned to the "modular-magician" user, it is either in the process of being autogenerated, or is planned to be autogenerated soon. If an issue is assigned to a user, that user is claiming responsibility for the issue. If an issue is assigned to "hashibot", a community member has claimed the issue already.

Terraform Version

`Terraform v0.11.10

  • provider.google v1.19.1
  • provider.google-beta v1.19.0`

Affected Resource(s)

  • google_container_cluster
  • master_authorized_networks_config

Terraform Configuration Files

resource "google_container_cluster" "google-beta" {
  name               = "kubernetes-cluster"
  region             = "us-central1"
  description        = "My Kubernetes cluster"
  min_master_version = "1.10.6-gke.6"

  node_pool = {
    name = "my-node-pool"


    initial_node_count = 1

    autoscaling {
      min_node_count = 1
      max_node_count = 5
    }

    node_config {
      disk_size_gb = 50
      disk_type    = "pd-standard"
      image_type   = "COS"
      machine_type = "custom-4-4096" 

      oauth_scopes = [
        "https://www.googleapis.com/auth/compute",
        "https://www.googleapis.com/auth/devstorage.read_only",
        "https://www.googleapis.com/auth/logging.write",
        "https://www.googleapis.com/auth/monitoring",
      ]
    }
  }

  maintenance_policy {
    daily_maintenance_window {
      start_time = "09:00" 
    }
  }

  master_authorized_networks_config {
    cidr_blocks = [
      "8.8.8.8/32",
      "4.4.4.4/32"
    ]
  }
}

Debug Output

Can share if needed, I need to rip out all the customer/account specific parts.

Panic Output

Expected Behavior

CIDR_BLOCKS can take an array as in the documentation.

I.e.

 cidr_blocks = [
      "8.8.8.8/32",
      "4.4.4.4/32"
  ]

Should set the allowed networks to connect to master on the kubernetes cluster.

Actual Behavior

While the validation works, the GCP provider errors on plan/apply:

Error: google_container_cluster.google-beta: master_authorized_networks_config.0.cidr_blocks.0: expected object, got string

Error: google_container_cluster.google-beta: master_authorized_networks_config.0.cidr_blocks.1: expected object, got string

Steps to Reproduce

  1. Create a kubernetes plan as above.
  2. Set a CIDR_BLOCKS to have an array of IP addresses.
  3. run terraform plan

Important Factoids

Oddly enough the YAML validation and terraform plan / apply will accept

    cidr_blocks {
      cidr_block = "8.8.8.8/32"
      cidr_block = "4.4.4.4/32"
    }

However only the last element in the cidr_block will be accepted and actually show up in the GUI. Terraform plan will also show you removing it if, for instance, you manually set it in the GUI and then are now running terraform plan
image

References

Terraform documentation on config element

Google documentation on allowing networks

bug

Most helpful comment

Full syntax would be

cidr_blocks = [
    {
        cidr_block = "8.8.8.8/32"
        display_name = "Net 1"
    },
    {
        cidr_block = "4.4.4.4/32"
        display_name = "something"
    },
]

All 7 comments

cidr_blocks = [
    { cidr_block = "8.8.8.8/32" },
    { cidr_block = "4.4.4.4/32" },
]

Full syntax would be

cidr_blocks = [
    {
        cidr_block = "8.8.8.8/32"
        display_name = "Net 1"
    },
    {
        cidr_block = "4.4.4.4/32"
        display_name = "something"
    },
]

@Chupaka is right - the documentation mentions that these are full blocks. Here is an excerpt:

The master_authorized_networks_config.cidr_blocks block supports:

  • cidr_block - (Optional) External network that can access Kubernetes master through HTTPS. Must be specified in CIDR notation.
  • display_name - (Optional) Field for users to identify CIDR blocks.

Bah, I don't know how I missed this -- thanks so much @Chupaka and @ndmckinley

Apologies, looks like this issue is still higher up in Google results than the more recent one on this same matter, which states that the syntax _is_ outdated as of Terraform 0.12.0. For posterity, if anyone else finds this, look at #4384

Just about a year later, I stumbled upon this issue, and tried the syntax @Chupaka suggested:

master_authorized_networks_config {
    cidr_blocks = [
      {
        cidr_block   = data.google_compute_subnetwork.subnetwork.ip_cidr_range
        display_name = "VPC"
      },
      {
        cidr_block   = "1.2.3.4/32"
        display_name = "Office static"
      },
    ]
    #cidr_block   = "4.2.3.1/32"
    #display_name = "Singularity"
    #cidr_block   = "10.20.30.40/32"
    #display_name = "Shadowcat"
  }

Terraform _formats_ it for me, so I'm thinking the _syntax_ itself is correct, but terraform plan yields and error:

$ terraform plan

Error: Unsupported argument

  on main.tf line 37, in resource "google_container_cluster" "primary":
  37:     cidr_blocks = [

An argument named "cidr_blocks" is not expected here. Did you mean to define a
block of type "cidr_blocks"?

Has anything changed in this block to make the previous suggestion outdated?

Terraform 0.12 removed the ability to use that syntax, consolidating on the format used by master_authorized_networks_config. This should be the correct syntax now:

master_authorized_networks_config {
  cidr_blocks {
    cidr_block   = data.google_compute_subnetwork.subnetwork.ip_cidr_range
    display_name = "VPC"
  }

  cidr_blocks {
    cidr_block   = "1.2.3.4/32"
    display_name = "Office static"
  }
}

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!

Was this page helpful?
0 / 5 - 0 ratings