The Policy agent can run in 3 different modes. Audit, Admission, and Terraform Admission and it can run in multiple modes in the same time.
Each mode has it's own logic and they all push their results to the Validations Sinks.
Currently there are three Kubernetes Custom Resources registered in the agent API
This is the main resource and it is used to define policies which will be evaluated by the policy agent.
See more about Policy CRD here
This is an optional resource. It is used to provide multiple policy configurations for the same policy for different resources, applications, namespaces and workspaces.
See more about PolicyConfig CRD here
This mode performs the audit functionality. It triggers per the specified interval (by default every 24 hour) and then lists all the resources in the cluster which the agent has access to read and validates those resources against the audit policies.
Works with policies of provider
kubernetes
This contains the admission module that enforces policies. It uses the controller-runtime
Kubernetes package to register a callback that will be called when the agent recieves an admission request. Once called, the agent will validate the received resource against the admission and tenant policies and k8s will use the result of this validation to either allow or reject the creation/update of said resource.
Works with policies of provider
kubernetes
Starting from version v2.2.0
, the policy agent will support mutating resources. To enable mutating resources set mutate
flag to true
in the admission
configuration section.
admission:
enabled: true
mutate: true # set this field to true to enable mutating resources
sinks:
filesystemSink:
fileName: admission.txt
See here how to make policies support mutating resources.
This is a webhook used to validate terraform plans. It is mainly used by the TF-Controller to enforce policies on terraform plans
Works with policies of provider
terraform
This sink is used to export validation results as kubernetes native events. Kubernetes event has a retention period and it set by default to 1 hour, you can configure the kubernetes api-server to update the period.
Configuration
sinks:
k8sEventsSink:
enabled: true
This sink sends the validation results to Flux Notification Controller.
Configuration
sinks:
fluxNotificationSink:
address: <>
File system sink writes the validation results to a text file. The file will be located at /logs/<filename>
Configuration
sinks:
fileSystemSink:
fileName: audit.txt
This sink stores the validation results in ElasticSearch. Here is the object schema.
Configuration
sinks:
elasticSink:
address: http://localhost:9200 # ElasticSearch server address
username: <elastic username> # User credentials to access ElasticSearch service
password: <elastic password> # User credentials to access ElasticSearch service
indexName: <index_name> # index name the results would be written in
insertionMode: <insertion mode> # It could be a choice of both insert or upsert, it defines the way the document is written.
-
insert
: would give an insight of all the historical data, doesn't update or delete any old records. so the index would contain a log for all validation objects. -
upsert
: Would update the old result of validating an entity against a policy happens in the same day, so the index would only contain the latest validation results for a policy and entity combination per day.
The config file is the single entry point for configuring the agent.
The agent needs the following parameters to be provided in the configuration yaml file:
kubeConfigFile
: path to the kubernetes config file to access the clusteraccountId
: unique identifier that signifies the owner of that agentclusterId
: unique identifier for the cluster that the agent will run against
There are additional parameters could be provided:
logLevel
: app log level (default: "info")probesListen
: address for the probes server to run on (default: ":9000")metricsAddress
: address the metric endpoint binds to (default: ":8080")audit
: defines cluster periodical audit configuration including the supported sinks (disabled by default)admission
: defines admission control configuration including the supported sinks and webhooks (disabled by default)tfAdmission
: defines terraform admission control configuration including the supported sinks (disabled by default)
Example
accountId: "account-id"
clusterId: "cluster-id"
kubeConfigFile: "/.kube/config"
logLevel: "Info"
admission:
enabled: true
sinks:
filesystemSink:
fileName: admission.txt
audit:
enabled: true
writeCompliance: true
sinks:
filesystemSink:
fileName: audit.txt
- Initial release
- Introduced Policy CRD
- Introduced PolicySet CRD
- Introduced PolicyConfig CRD
- Added
mode
field to PolicySet CRD - Added
status.modes
field to Policy CRD
- Remove PolicySet CRD
See the Development guide here