inspec-gcp icon indicating copy to clipboard operation
inspec-gcp copied to clipboard

Using google_access_context_manager_access_policies() fails to bring back any policies

Open sukchomb-zz opened this issue 5 years ago • 9 comments

Describe the problem

Requested in https://github.com/inspec/inspec-gcp/issues/215 and fixed in https://github.com/inspec/inspec-gcp/pull/218 (now closed)

I can see the policies via

gcloud access-context-manager policies list --organization

But using the GCP resource pulls back nothing.

Possible Solution

Upon further investigation with Google it transpires that using V1 of accessPolicies.get works fine V1aplha of the same always gives me errors code 403 : Permission denied

Please check the api in these other related resources:

google_access_context_manager_access_policy, google_access_context_manager_service_perimeter, google_access_context_manager_service_perimeters

Please advise when the V1 of the API will be used.

sukchomb-zz avatar Feb 11 '20 10:02 sukchomb-zz

Browsing the resource code shows it is using V1 of the api https://github.com/inspec/inspec-gcp/blob/master/libraries/google_access_context_manager_access_policy.rb#L62

However not sure why V1 works successfully in the console but not within inspec.

sukchomb-zz avatar Feb 11 '20 13:02 sukchomb-zz

I cannot reproduce this @sukchomb. Can you show some cut and pastes of the issue please?

lhasadreams avatar Mar 02 '20 15:03 lhasadreams

@lhasadreams , @slevenick Using command line

gcloud  access-context-manager policies list --organization 233526418605
NAME          ORGANIZATION  TITLE
656908083570  233526418605  service-control-1

However , nothing is pulled back when done via inspec version 4.18.97

google_access_context_manager_access_policies(org_id: '233526418605').names.each do |policy_name|

    Inspec::Log.info("Policy name is #{policy_name}")

    describe google_access_context_manager_access_policy(name: policy_name) do
      it { should exist }
      its('title')  { should_not cmp '' }
      its('parent') { should match '233526418605' }
    end

sukchomb-zz avatar Mar 02 '20 19:03 sukchomb-zz

Hey @sukchomb that's unusual. That control looks correct, is there any chance that you are using different credentials for your gcloud command and executing the InSpec controls? If your service account doesn't have permissions to view the access policies it would cause this result

slevenick avatar Mar 02 '20 20:03 slevenick

Hi @slevenick , @lhasadreams , I'm using the same credentials for both tests and requested Paul to also try the same 2 tests, and he's confirmed that the Inspec test brings nothing back.

We both have org level access as the gcloud command confirms.

Can you take a look please.

sukchomb-zz avatar Mar 03 '20 16:03 sukchomb-zz

I'm able to run the integration tests that include a test against this resource:

  ✔  google_access_context_manager_access_policy-1.0: google_access_context_manager_access_policy resource test
     ✔  AccessPolicy 677756614847 is expected to exist
     ✔  AccessPolicy 677756614847 title is expected to cmp == "policytitle"
     ✔  AccessPolicy 677756614847 parent is expected to match "953310715741"
  ✔  gcp-storage-bucket-iam-binding-1.0: Ensure storage bucket IAM binding has the correct properties.

From running this test:


  describe.one do
    google_access_context_manager_access_policies(org_id: gcp_organization_id).names.each do |policy_name|
      describe google_access_context_manager_access_policy(name: policy_name) do
        it { should exist }
        its('title') { should cmp service_perimeter['policy_title'] }
        its('parent') { should match gcp_organization_id }
      end
    end
  end

And

  ✔  google_access_context_manager_access_policies-1.0: google_access_context_manager_access_policies resource test
     ✔  google_access_context_manager_access_policies count is expected to be >= 1
     ✔  google_access_context_manager_access_policies titles is expected to include "policytitle"

From this test:

  describe google_access_context_manager_access_policies(org_id: gcp_organization_id) do
    its('count') { should be >= 1 }
    its('titles') { should include service_perimeter['policy_title'] }
  end

So I believe that the resource is currently working. Are you able to retrieve information about these access policies via the REST API on the sidebar here? https://cloud.google.com/access-context-manager/docs/reference/rest/v1/accessPolicies/list

Note that on that sidebar the parent field is required and should be in the form organizations/{org_id}

slevenick avatar Mar 03 '20 17:03 slevenick

Hi @slevenick , @lhasadreams

Calling https://cloud.google.com/access-context-manager/docs/reference/rest/v1/accessPolicies/list

fails and I've even tried v1alpha , v1beta and the response is still the same

{
  "error": {
    "code": 403,
    "message": "The caller does not have permission",
    "status": "PERMISSION_DENIED"
  }
}

And yet I can execute the gcloud command successfully.

gcloud access-context-manager policies list --organization 233526418605
NAME          ORGANIZATION  TITLE
656908083570  233526418605  service-control-1

Raising support case with Google.

sukchomb-zz avatar Mar 04 '20 13:03 sukchomb-zz

I edited the code to give us a better error message. It looks like running as a user is the problem not the inspec resource itself. We need to run as a service account.

{"error"=>{"code"=>403, "message"=>"Your application has authenticated using end user credentials from the Google Cloud SDK or Google Cloud Shell which are not supported by the accesscontextmanager.googleapis.com. We recommend configuring the billing/quota_project setting in gcloud or using a service account through the auth/impersonate_service_account setting. For more information about service accounts and how to use them in your application, see https://cloud.google.com/docs/authentication/.", "status"=>"PERMISSION_DENIED"}}

pburnet-lbg avatar Mar 05 '20 16:03 pburnet-lbg

Ah, that makes sense. Sorry that the error wasn't readily visible, but generally it's difficult to pull any useful information from 403/404 errors and they are often interchangeable.

Running as a service account is the general recommendation for InSpec GCP, as there may be several APIs that enforce this restriction.

I'm going to keep this open as a reminder for me to put a note on the access context manager resources that authentication must be done as a service account

slevenick avatar Mar 05 '20 23:03 slevenick