Home Explore Blog CI



kubernetes

2nd chunk of `content/en/blog/_posts/2016-12-00-From-Network-Policies-To-Security-Policies.md`
9e5a15055db7a9f70505e3690d1306d032ade7674c6e09c700000001000002f5
![](https://lh3.googleusercontent.com/PhkJ4eoRc50gm6oSTZbw138l3jzVKjjQrn2mNHjys9Cu7RG-q2X-f5PX07ZY6xjbIQT0ud8oMSX6yNwjDpmDq3a3lYWcc_gBYJBjvBLP8PIHZaTW54fJppDze9pYxOmZY-JNqQ1Y)

The Trireme implementation talks directly to the Kubernetes master without an external controller and receives notifications on policy updates and pod instantiations so that it can maintain a local cache of the policy and update the authorization rules as needed. There is no requirement for any shared state between Trireme components that needs to be synchronized. Trireme can be deployed either as a standalone process in every worker or by using [Daemon Sets](/docs/admin/daemons/). In the latter case, Kubernetes takes ownership of the lifecycle of the Trireme pods.   

Title: Trireme Implementation Details
Summary
Trireme interacts directly with the Kubernetes master to receive updates on policy and pod instantiations, maintaining a local policy cache and updating authorization rules without requiring shared state synchronization. It can be deployed as a standalone process or through Daemon Sets, managed by Kubernetes for lifecycle management.