CODEWITHSUNDEEP
google-cloud-platformvpcgoogle-vpc
Ankit Srivastava
Ankit Srivastava

Reputation: 65

VPC SC Service Perimeter handle Google Service Accounts

I have a service perimeter created on projects holding Cloud Composer.

The VPC SC Logs snippet are below,

    "authenticationInfo": {
      "principalEmail": "service-org-<ORG_ID>@security-center-api.iam.gserviceaccount.com"
    },
    "requestMetadata": {
      "callerIp": "private",
      "requestAttributes": {},
      "destinationAttributes": {}
    },
    "serviceName": "compute.googleapis.com",
    "methodName": "compute.beta.DisksService.Insert",
"resourceName": "projects/<CloudComposerProjectNumber>",
"violationReason": "RESOURCES_NOT_IN_SAME_SERVICE_PERIMETER",
"egressViolations": [
        {
          "source": "projects/<CloudComposerProjectNumber>",
          "sourceType": "Resource",
          "servicePerimeter": "accessPolicies/number/servicePerimeters/perimeter_name",
          "targetResource": "projects/<ProjectNumbernotfound>"
        }
      ]

I feel the error is because I don't have any access level defined for these Google Owned Service Accounts. But since the violation reason is NOT_IN_SAME_SERVICE_PERIMETER I don't think that is the reason. The target project number is not found in my estate. Could it be external or google owned? I tried adding egress rule for identity "service-org-<ORG_ID>@security-center-api.iam.gserviceaccount.com" but it is failing Error 400: The email address 'service-org-<ORG_ID>@security-center-api.iam.gserviceaccount.com ' is invalid or non-existent.

Not sure if anyone has something similar

Upvotes: 0

Views: 308

Answers (2)

balkez
balkez

Reputation: 21

The violations errors are referring to disk cloning operations which are being performed regularly as part of Virtual Machine Threat Detection (VMTD) services [1] (which must be enabled on SCC Premium at Organization level).

Furthermore, when analyzing the log we can see the source project being your Cloud Composer project and the target project being a Google-managed one with the method “compute.beta.DisksService.Insert” being called to clone the disk.

Moreover, to address this matter, you should configure an egress rule [2] to allow SCC service agent SA to invoke “compute.beta.DisksService.Insert” to the Google-managed project related to SCC VMTD.

This behavior is somewhat explained in this documentation [3] on the limitations section.

[1] https://cloud.google.com/security-command-center/docs/concepts-vm-threat-detection-overview

[2] https://cloud.google.com/vpc-service-controls/docs/ingress-egress-rules#egress-rules-reference

[3] https://cloud.google.com/security-command-center/docs/concepts-vm-threat-detection-overview#limitations:~:text=VM%20Threat%20Detection%20requires,scanning%20might%20not%20work.

Upvotes: 2

x-zone-cat
x-zone-cat

Reputation: 552

Usually the said error means that resources being accessed don't have a common Service Perimeter. You may check the corresponding resourceName field on the audit logs. See also the following list to verify your issue:

  • Make sure that all resources listed in resourceNames are within the same service perimeter.

  • If the resources are in different perimeters, a perimeter bridge is required to share resources across perimeters.

  • To connect the resources' projects, especially if they are from different organizations, use an ingress/egress rule.

Upvotes: 0

Related Questions