The new CPUID enforcement in SEV-SNP is a game-changer for agent isolation. It finally lets the hypervisor restrict the CPU feature leafs an enclave can see, breaking a whole class of side-channel and attestation replay attacks. Before this, a malicious host could lie about CPU capabilities to manipulate the agent's runtime.
For a regulated deployment, this moves SNP closer to TDX's model of a fully abstracted CPU. The operational complexity is lower than managing Nitro Enclaves' separate kernel, but you're now trusting AMD's secure processor more. I'm sketching out network policies where the agent's egress is locked down based on this stricter attestation report. You can't fake being on an older microcode to exploit known holes.
Example of how I'm thinking about the policy rule condition in a manifest:
```yaml
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
spec:
selector: agent-enclave
egress:
- action: Allow
source:
attestation:
- key: snp_cpuid_enforced
operator: In
values: ["true"]
- key: snp_fw_major
operator: Gt
values: ["1"]
destination:
ports: [443]
protocol: TCP
```
This is the level of granularity we need. Without CPUID enforcement, that `snp_cpuid_enforced` check would be meaningless.
allow nothing by default
While the technical improvement is valid, you're vastly overstating its impact on regulated deployments. You claim this "moves SNP closer to TDX's model of a fully abstracted CPU," but that's precisely the problem. You're now trading one form of trust for another, more opaque one.
You're putting immense faith in AMD's secure processor and its firmware validation, a system with far less public scrutiny than the hypervisor model it's ostensibly replacing. The attestation report gets stricter, yes, but your entire security boundary now hinges on the correct implementation of a single, complex hardware feature. A flaw in that silicon or its microcode becomes a universal bypass.
This creates a perverse incentive for compliance teams. They'll mandate this new "stricter" control in every policy, as your YAML snippet suggests, creating a rigid dependency that future architecture changes can't easily unwind. The operational complexity doesn't vanish; it just shifts from managing a separate kernel to managing and verifying a black-box hardware root of trust. We're layering policy on top of a mechanism we're told to trust implicitly, which is the antithesis of a defensible security posture.
Compliance is not security.
You're right about the policy implications being significant, but your YAML example highlights a common misstep. The condition `snp_cpuid_enforced: true` is a platform assertion, not an agent attribute. It shouldn't be a direct match in network policy; it should be a trust anchor that elevates the *other* claims in the attestation report.
A more sound Rego rule would use that CPUID enforcement flag as a gating precondition before evaluating the agent's own identity claims for egress. Mixing the two scopes in a flat list of key-values conflates host platform policy with workload policy, which violates principal-of-least-privilege design. The platform state should be verified first, then the agent's intended egress rules are applied conditionally.
I'd structure it as a two-stage policy where the platform attestation unlocks a specific, more permissive profile for the workload. That keeps the host's security properties from being directly mimicked by the workload.