I have been conducting a systematic evaluation of Orca Security's agentless scanning capabilities across a fleet of approximately 200 EC2 instances in our development and staging AWS accounts. My standard procedure involves deploying a known-good configuration baseline, initiating a full scan, and then measuring the time-to-complete and the resulting CVE inventory as a form of performance and efficacy benchmark.
However, in my latest controlled test run, I am observing a persistent issue where 37 of the 200 instances consistently report a status of 'unscanned' in the Orca dashboard, despite the account connector showing a healthy state and successful scanning of the other 163 instances. This is disrupting my ability to generate a reproducible, complete dataset for my security posture benchmarking.
I have followed the standard troubleshooting steps as per Orca's documentation. The affected instances are a mix of `t3.large` and `m5.xlarge` types, all running Amazon Linux 2. They reside in three separate VPCs, but the issue is not isolated to a single network or subnet. The security groups attached to these instances have been validated to allow the necessary egress traffic to Orca's published IP ranges and domains on ports 443 and 80.
My current diagnostic data and configuration checks include:
* **Connector IAM Policy:** I have cross-referenced the attached IAM policy with Orca's required permissions document. The policy includes `ec2:DescribeInstances`, `ec2:DescribeImages`, `ssm:GetParameter`, and the other listed read-only actions. No recent changes have been made.
```json
{
"Effect": "Allow",
"Action": [
"ec2:DescribeInstances",
"ec2:DescribeImages",
"ssm:GetParameter"
],
"Resource": "*"
}
```
* **Instance State:** All 37 instances are in the `running` state. They have the AWS SSM Agent running (version 3.1.642.0), which is a prerequisite for the agentless scanning to function via the Systems Manager channel.
* **Network Diagnostics:** I have run a packet capture test from a sample affected instance, confirming TCP connectivity can be established to `api.orcasecurity.io` on port 443.
Given the partial success of the scan (79% coverage), this suggests a systemic issue with a specific subset of instances rather than a total account-level failure. My next step would be to enable DEBUG-level logging for the Orca sidecar, but I am seeking guidance on the most efficient diagnostic path.
Has anyone else encountered a pattern of intermittent 'unscanned' statuses within an otherwise functional environment? Specifically, are there known limitations or required configurations related to:
* Instance metadata service (IMDS) versions or hop limits?
* Specific SSM Agent parameters or state?
* The handling of instances launched from custom AMIs versus AWS-provided ones?
I intend to document the root cause and resolution process thoroughly for the benefit of others attempting to validate scanning completeness.
-- bb42
-- bb42
Classic. I ran into this with their agentless setup last year. Their docs are useless for it.
It's almost certainly a permissions or IAM role boundary issue on those specific instances, even if the connector looks fine. The error reporting in the dashboard is bad. You need to check the CloudTrail logs for the Orca role in those specific accounts during the scan window, look for explicit denies. It'll be something stupid, like a missing `ec2:DescribeInstances` on a weird resource ARN pattern for those three VPCs.
CRM is a necessary evil
Interesting. We're looking at Orca too. I've seen a similar unscanned issue, but ours was tied to the specific AMI version on a few instances. Have you confirmed the affected VMs are all on the same AMI ID? Even on Amazon Linux 2, a slightly older patch version sometimes trips things up.
Had that AMI theory myself, but it was a red herring. Orca's scanning just gets weird with certain EC2 instance metadata states, especially on spot instances that have been stopped/started a bunch. Their agentless model gets cranky.
CRM is a means, not an end.