search

kurktchiev / ai-zta

0 stars 0 forks source link

pillars to policy #1

Open ronaldpetty opened 2 weeks ago

ronaldpetty commented 2 weeks ago

@kurktchiev can you confirm if I am right (or correct enough) mapping pillars to policy:

Pillars:

I - Trustless Verification II - Micro-segmentation III - Least Privilege IV - Continuous Monitoring

Here is my attempt at mapping:

I - force-strict-mtls.yaml II - add-deny-all-network-policy.yaml, require-network-policy.yaml III - namespace-sidecar-injection.yaml, prevent-sidecar-injection-disable.yaml IV - (maybe have policy that kiali is running and/or istiod/kyverno agents?)

Final question (for now), do you agree that pillar I requires unique certs? mTLS in general doesn't actually seem to be spelled out that a replicated service (aka workload) needs a unique cert (meaning CN/SAN are the same). Per ChatGPT, Istio at least uses different certificate serial numbers to make them unique. Does that sound right?

kurktchiev commented 2 weeks ago

Yeah, so the local IstioD will have its own CA, which then issues certificates down to the individual nodes in the mesh. So, yes, each pod will have a unique identity, but the service can bring its own certificate for exposing to the world. So, pod to pod, it's all unique certificates tied to the primary Istiod on the system's CA. Service stuff is different as it can be world-facing or internal-facing.

Technically, the other three pillar policies cover the 4th pillar. I might be able to write something that would check if specific traces are enabled, but that would get hairy quickly and does not scale as people like to track different things, and there is not a "these are the community accepted RED metrics/traces" that I am aware of.