I've been evaluating Lacework's CSPM capabilities against several other platforms (Wiz, Prisma Cloud, etc.) and have hit a consistent blocker during my GCP organization-level integration setup. The integration successfully authenticates and begins data ingestion, but it consistently fails to pull in all projects under the organization node.
From my benchmark logs, it appears the integration is only discovering and monitoring approximately 60-70% of the expected projects. The missing projects seem random across folders; they are not confined to a single branch of the resource hierarchy. This creates a significant gap in coverage for a comparative security posture assessment.
My configuration follows the standard Terraform module for Lacework GCP organization integration. The service account has the required `roles/browser` and `roles/cloudasset.viewer` at the organization level, and the organization itself is correctly specified.
```hcl
module "lacework_gcp_org_agentless_scanning" {
source = "lacework/agentless-scanning/gcp"
version = "~> 0.3"
org_integration = true
organization_id = "my-organization-id"
}
```
Has anyone else encountered this partial project discovery issue? I've already verified:
* There are no Organization Policy constraints denying service account access.
* The missing projects are active and not suspended.
* The `gcloud asset search-all-resources` command, using the same service account, returns the full project list.
I'm looking for any specific, concrete configuration parameters or known constraints—such as API quotas, pagination limits in the Lacework collector, or required permissions beyond the documented ones—that could cause this behavior. My next step is to run a side-by-side API call trace against another tool that is successfully enumerating all projects, but community insight would be valuable.
BenchMark
Interesting, we saw something similar last quarter. Our missing projects were often the ones created via automation pipelines, like Terraform or Deployment Manager, right after the integration was first configured.
Did you check if those projects have the Cloud Asset API enabled? That was the gotcha for us. Even with the viewer role, if the API isn't enabled on a project, it won't show up in the inventory.
Are you filtering by label at all? I missed that in my first setup and it silently excluded a bunch of things.
>if the API isn't enabled on a project, it won't show up in the inventory.
That's it. Ran into this with a project that had all APIs disabled by a security baseline policy.
Also, check your service account's Org Viewer role assignment scope. If it's applied to a folder and not the org root, new subfolders won't inherit it.
Benchmarks or bust.
You've configured the key permissions at the organizational level, which is correct. However, the partial discovery you're describing strongly suggests a resource constraint or an API governance policy is interrupting the enumeration.
Two specific checks beyond the service account role come to mind. First, confirm there isn't a quota limit on the Cloud Asset Inventory export you're using; a full organization dump can hit request or size limits, causing a silent truncation. Second, and this is critical for a true comparative benchmark, verify the organization's Access Transparency logs for any denied data access events during the sync window. A conditional IAM policy or a VPC Service Controls perimeter could be selectively filtering projects based on network tags or compliance violations, which would align with the "random across folders" pattern you're seeing.
For your matrix, you'll need to document whether this is a platform limitation or an environmental constraint, as that changes the scoring criteria for your CSPM evaluation. Have you reviewed the operation logs for the specific Cloud Asset export job Lacework initiates?
RTFM — then ask for the audit
Good observations from others on API enablement and IAM scope. Since you've already got the org-level roles assigned, I'd look at the sync timing and the asset inventory snapshot mechanism itself.
Lacework's organization integration relies on a scheduled export to a sink bucket. If that export job is failing partway through due to timeouts on a large resource hierarchy, it'll give you partial data without always surfacing an obvious error. Check the Cloud Scheduler job and the Pub/Sub topic for the export; look for execution failures or backlogged messages around your sync windows.
Also, verify the sink bucket's location. If you have projects scattered across multiple regions and your bucket is in a single region, you might be hitting data residency rules that block certain project assets from being written, effectively filtering them out.
Mike
Yeah, the Terraform module sets the baseline, but it won't handle post-creation drift. Your missing 30-40% is a big red flag for a process issue, not config.
Two things to rule out immediately:
1. Run a one-off asset inventory export using the same service account and sink bucket. Compare the project count in that dump to what Lacework shows. If they match, the issue is upstream in GCP. If they don't, it's in the Lacework ingestion.
2. Check if you have any Organization Policies like `constraints/compute.disableGuestAttributesAccess` or VPC-SC perimeters that could be blocking the agentless scanner's specific queries for certain projects. These can cause silent drops.
Also, open a support ticket with Lacework and ask for the raw project list from their last sync. Their internal queue for processing those bucket exports can get backed up.
Integration is not a project, it's a lifestyle.
>Open a support ticket with Lacework and ask for the raw project list
This is the first truly useful suggestion in the thread. Everyone else is playing detective with your GCP config, but if you're paying for a service, make them show you the data. Their ingestion pipeline is a black box, and they're the only ones with the logs.
That said, the one-off export comparison is good in theory, but in my experience, the timing never lines up. By the time you run your manual export, Lacework's scheduled job has already picked up a new, slightly different snapshot. You're comparing two moving targets.
The 30-40% gap screams a filtering rule somewhere, either on their side or in a policy you've forgotten about. Have you checked for any *conditional* role bindings on that service account? Those can get weird with inheritance.
Trust but verify.
Good catch on the config - the Terraform module is solid for the initial grant, but it won't retroactively enable APIs on projects created before the integration. That's likely your culprit for the older, automated projects.
I'd add a step to your assessment: script a quick check across all projects to verify the Cloud Asset API is enabled. You can use `gcloud services list --enabled` per project. If you find any with it off, that's your missing chunk.
Also, double-check that your organization ID in the module doesn't have any typos. I once spent a day debugging because I used the numeric ID when the field expected the string name.
That's a really insightful point about the Access Transparency logs; I hadn't considered checking for a conditional deny from something like VPC-SC. It would explain the seemingly random pattern perfectly. When you mention quota limits on the export, do you know if that would typically throw an error in the Cloud Scheduler logs, or does it just fail silently with a partial dump?
This makes me wonder, for the sake of my comparison, how this potential silent truncation in Lacework stacks up against how a platform like Wiz handles a full organization sync. Do you know if they use a different ingestion method that might avoid these bulk export limits?
For an evaluation that's supposed to compare platforms, you're starting off on the wrong foot by accepting their black box integration as gospel. You're letting the vendor define your coverage metric.
The real question isn't "why are 30% of my projects missing?", it's "why am I paying for a platform that can't even tell me which 30% are missing?" Their dashboard shows you a percentage, not a list. That's intentional. It lets them argue about your GCP setup while deflecting from their own ingestion reliability.
Open a ticket and demand the raw project IDs from their last successful sync. Not a summary, the actual list. If they can't provide that, you've just uncovered your first major differentiator for your benchmark. Then run your own gcloud asset export and diff the lists yourself. The discrepancy is your answer.
Show me the unit economics.
> Has anyone else encountered this partial project discovery
Yes, and it's almost never the Terraform module. The module does its job and then the real problems start.
You've gotten good advice about checking API enablement and VPC-SC, but for a benchmark, you need to isolate the failure domain. Run this command with your service account's key to see what GCP actually thinks you can see:
```bash
gcloud asset search-all-resources --scope=organizations/YOUR_ORG_ID --asset-types="cloudresourcemanager.googleapis.com/Project" --page-size=1000 --format="table(name)" | wc -l
```
Compare that count to what Lacework reports. If they match, the problem is in GCP's delivery. If they don't, Lacework's ingestion pipeline is dropping data. It's that simple.
Also, scrap the percentage. Work with absolute project lists. A diff will show you if the missing projects share a label, zone, or creation date. Random across folders usually points to a resource constraint or a timing issue in the export job.
Your fancy demo doesn't scale.
That gcloud asset search command is the right diagnostic, but I'd caution against using `wc -l` on the table output. The `search-all-resources` command paginates, and the table format only shows the *display* name. You need to capture the full asset name which includes the unique numeric project ID.
A more accurate comparison uses JSON output and processes the full pagination:
```bash
gcloud asset search-all-resources
--scope=organizations/YOUR_ORG_ID
--asset-types="cloudresourcemanager.googleapis.com/Project"
--format="json(name)" | jq '.[].name' | sort > gcp_projects.txt
```
Get the line count from that file. The numeric ID is critical because your manual diff will fail if two projects share a display name in different folders. The absolute list is indeed the only way to find a pattern, like if all missing projects have a specific label key for automated deployments.
every dollar counts
Yeah, the gcloud asset search suggestion is solid. That seems like the quickest way to tell if it's a GCP permissions issue or Lacework dropping data.
I'm dealing with something similar on Azure. What did you find when you compared the counts? Did the gcloud command show all your projects?
Still learning
Oh, that's interesting you're seeing this on Azure too! I haven't run the gcloud command yet - I'm still a bit nervous about using the CLI for something this important 😅. I was hoping the console would have a clearer way to check.
But since you mentioned Azure, does your platform have a similar diagnostic command? Or is the process totally different over there? I'm curious if this is a common cloud provider problem or specific to GCP's setup.