https://docs.otterize.com/reference/intents-and-intents-files#intents-file-specification

This seemed great for defining intents for IntraCluster Network Communication. But then we have policies like not allowing egress connections or would be hard to define if then do policies.

But this seems apt for what they claim to do
If developers just declare what their code intends to access, then an automated system can configure security controls to allow this access, while blocking any unintended access.
We can extend the same spec for certain zero trust system policies as well.

selector:
calls:
 - type: capabilities
   resources: [SYS_NET_ADMIN]

Should our spec be something like

selector:
spec:
 - action: Audit/Allow/Block
   type: capabilities
   resources: [SYS_NET_ADMIN]

now type and resources are configurable. It can be presets or generic stuff

selector: svc.a
spec:
 - action: Block
   type: network
   resources: [maliciousip, svc.b]

Here svc.a is denied access to both maliciousip preset or svc.b as well

For KubeArmor policies

selector: deployment.a.knownprocesslist
spec:
 - action: Allow
   type: system/fs
   resources: [sensitive-assets, "/etc/certs"]

Question: Can we define knownprocesslist preset in CEL selector? and have DE generate policies policies based on that?

These are vague thoughts, I am still trying to organise them but I have a feeling this maybe closer to what we want in the intent.

Key Point here are preset keywords

knownprocesslist for example would probably be generated by DE or could be preset

The source of this could be another CR. these keywords would be defined in a kubernetes resource which will be updated by something like DE and operator would refer them through CEL

selector: deployment.a.knownprocesslist
spec:
 - action: Allow
   type: system/fs
   resources: [sensitive-assets, "/etc/certs"]

selector: deployment.a
spec:
 - action: Allow
   type: system/fs
   resources: [malprocesslist]

Possible types

capabilities
system/fs
system/fs readonly
network
network-ingress
network-egress

1. Do not allow privilege escalation

selector:
spec:
 - action: Audit/Allow/Block
   type: capabilities
   resources: [SYS_NET_ADMIN]

3. Do not allow egress connections on pods which are directly connected to public networks
4. Allow only certain APIS to be called on ingress of microservice X.
5. Generate CIS compliance
6. If malicious IP is detected, then do X
7. RBAC Access

selector: Subjects
spec:
 - action: Allow
   type: Roles
   resources: [clusterrole]