Unable to test user labels on Cloud SQL instances using latest resource pack

[sukchomb-zz]

Describe the problem

Hi @lhasadreams , @skpaterson @slevenick
The recent gcp resource pack release has broken the way we detect the presence of labels on database settings, specifically user labels, this section of code was previously working

  google_sql_database_instances(project: gcp_project_id).where(instance_version: /MYSQL_/).instance_names.each do |instance_name|

    this_instance = google_sql_database_instance(project: gcp_project_id, database: instance_name)

    if this_instance.settings.respond_to?('user_labels')

Now the 'respond_to? test always yields 'false' and skips the rest of the test.

When I jump into pry, I can see the user labels but only when I cd into the 'this_instance' object:

@fetched.fetch('settings').fetch('userLabels').fetch('dataclassification')
=> "confidential"

When I jump into the settings object, user labels are not exposed

[4] pry(#<#<Class:0x00007fc40a8f1210>::GoogleInSpec::SQL::Property::DatabaseInstanceSettings>):2> ls
#<Class:0x00007fc40a8f1210>::GoogleInSpec::SQL::Property::DatabaseInstanceSettings#methods: availability_type  backup_configuration  database_flags  ip_configuration  settings_version  tier  to_s
self.methods: __pry__
instance variables: @availability_type  @backup_configuration  @database_flags  @ip_configuration  @parent_identifier  @settings_version  @tier
locals: _  __  _dir_  _ex_  _file_  _in_  _out_  _pry_

I'm not sure how I can work around this in the contex
Can these be restored at the earliest opportunity please?

Possible Solution

Possibly extract out the values using a combination of inspect and regex

[sukchomb-zz]

We are using inspec version 4.18.100

[sukchomb-zz]

The same issues exists for the disk encryption configuration.

if this_instance.respond_to?(:disk_encryption_configuration)

Here I can see the data when inspecting the response:

"diskEncryptionConfiguration"=>{"kmsKeyName"=>"projects/tfci-ci1-tst-3369/locations/europe-west2/keyRings/my_key_ring_name/cryptoKeys/my-key-using-hsm", "kind"=>"sql#diskEncryptionConfiguration"},

[sukchomb-zz]

Same behaviour with Inspec version 4.18.104

[slevenick]

Hey @sukchomb

The changes to remove respond_to? as a critical part of controls is intentional. On older resources respond_to? had to be checked as methods were not generated unless the API responded with a non-nil value for that particular method.

Ideally, the new control would be simplified and look something like this:

  google_sql_database_instances(project: gcp_project_id).where(instance_version: /MYSQL_/).instance_names.each do |instance_name|

    this_instance = google_sql_database_instance(project: gcp_project_id, database: instance_name)

  # Test for each instance
  describe this_instance do
    its('user_labels') { should include ... }
    

Or:

  google_sql_database_instances(project: gcp_project_id).where(instance_version: /MYSQL_/).instance_names.each do |instance_name|

    this_instance = google_sql_database_instance(project: gcp_project_id, database: instance_name)

  unless this_instance.user_labels.nil? do
    specific tests for instances with user_labels defined
  end

The problem in this case is that the new generated sql_database_instance doesn't have user_labels defined. That's an easy fix from my end though, should have it out in the next couple days

[sukchomb-zz]

@slevenick Thanks for the quick response - much appreciated 👍