Skip to main content
Version: 0.29.0

Policy Profile Enterprise

Overview

Weave policy profile provides policies to automate the enforcement of best practices and conventions. It ensures the compliance of workloads through the use of a policy agent that provides an admission controller webhook that stops violating resources from deploying to a cluster and runs a daily audit that reports violating resources already deployed.

The profile configuration contains two main sections policySource to configure the source for deploying policies and policy-agent to configure the policy agent.

Expand for an example of the profile values file
policy-agent:
failurePolicy: Ignore

# If you don't want to use cert-manager, set useCertManager to false and provide your own certs
useCertManager: true
certificate: ""
key: ""
caCertificate: ""

persistence:
enabled: false
# claimStorage: 1Gi
# sinkDir: /tmp
# storageClassName: standard

config:
accountId: ""
clusterId: ""

audit:
# Enable audit functionality
enabled: false
# sinks:
# # Enable writing violations as K8s events
# k8sEventsSink:
# enabled: true

admission:
# Enable admission functionality
enabled: true
# mutate: true # enable mutating violating resources
sinks:
# Enable writing violations as K8s events
k8sEventsSink:
enabled: true


policySource:
enabled: false
# url: ssh://git@github.com/weaveworks/policy-library
# tag: v1.0.0
# branch:
# path: ./ # Could be a path to the policies dir or a kustomization.yaml file
# secretRef: policy-library-auth # (Optional): Name of the K8s secret with private repo auth credentials
# sourceRef: # Could specify a name for an existing GitSource reference instead of creating a new one
# kind: GitRepository
# name: policy-library
# namespace: flux-system

Policy Sources

Policies are provided in the profile as Custom Resources. The agent reads from the policies deployed on the cluster and runs them during each admission request or when auditing a resource.

Policies are hosted in a policy library which is usually a git repository. They are fetched in the profile through the use of kustomize.toolkit.fluxcd.io.Kustomization, that deploys the policies to the cluster.

By default all policies in the specified path would be deployed in order to specify which policies should be deployed in a library, a kustomize.config.k8s.io.Kustomization file should be defined in the repository.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources: # specifies the path to each required policy
- policies/ControllerContainerAllowingPrivilegeEscalation/policy.yaml
- policies/ControllerContainerRunningAsRoot/policy.yaml
- policies/ControllerReadOnlyFileSystem/policy.yaml

The profile then needs to be configured with the necessary config to be able to reach the repository that is acting as a policy library.

policySource:
enabled: true
url: URL of the repo where your policies exist
tag: tag name on the policies repo
path: Path to the policies dir - or a kustomization.yaml that selects some policies - in the repo
secretRef (if the repo is private): Name of the K8s secret with private repo credentials (leave empty if the repo is public)

There is the option of referencing an existing policy library source instead of creating a new one.

policySource:
enabled: true
sourceRef:
kind: Kind of the existing source
name: Name of the policy library source
namespace: Namespace where the source exists

Policy Agent Configuration

The config section is the single entry point for configuring the agent.

The agent needs the following parameters to be provided in the configuration yaml file:

  • accountId: unique identifier that signifies the owner of that agent
  • clusterId: unique identifier for the cluster that the agent will run against

The following optional parameters can also 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")

Agent Modes

Admission

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 receives 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

To enable admission control:

policy-agent:
config:
admission:
enabled: true

Enabling admission controller requires certificates for secure communication with the webhook client and the admission server. The best way to achieve this is by installing cert manager and then configuring the profile as follows:

policy-agent:
useCertManager: true

The cert manager can also be installed by installing the cert manager profile while creating the cluster.

There is the option of providing previously generated certificates although it is not recommended and it is up to the user to manage it:

policy-agent:
certificate: "---" # admission server certificate
key: "---" # admission server private key
caCertificate: "---" # CA bundle to validate the webhook server, used by the client

If the agent webhook could not be reached or the request failed to complete, the corresponding request would be refused. To change that behavior and accepts the request in cases of failure, this needs to be set:

policy-agent:
failurePolicy: Ignore

Audit

The audit functionality provides a full scan of the cluster(s) and reports back policy violations. This usually is used for policy violations reporting, and compliance posture analysis against known benchmarks like PCI DSS, CIS, .etc.

Works with policies of provider kubernetes

To enable the audit functionality:

policy-agent:
config:
audit:
enabled: true
interval: 24 # configuring the frequent of audit operations running in hours (default is 24 hours)

The audit will be performed when the agent starts and then again periodically at an interval of your choice in hours (default is 24 hours). The results of the audit will be published to the configured sink(s).

Terraform Admission

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

To enable the terraform admission control:

policy-agent:
config:
tfAdmission:
enabled: true

Policy Validation Sinks

When validating a resource, a validation object is generated that contains information about the status of that validation and metadata about the resource and policy involved. These objects can be exported to be visible for users as a critical part of the audit flow, but can also be useful as logs for the admission scenario.

By default, the agent only writes policy validations that are violating a certain policy when performing an audit. To write compliance results as well, the following needs to be specified in the profile:

policy-agent:
config:
audit:
writeCompliance: true

The agent profile supports storing the validations in different sinks. Multiple sinks can be used at the same time:

The results will be dumped into a text file in the logs directory, in the agent container as a json string. It is important to note that this file will not be persisted and will be deleted upon pod restart, so generally this approach is not recommended for a production environment.

To enable writing to a text file in audit scenario:

policy-agent:
config:
audit:
sinks:
fileSystemSink:
fileName: "file.json"

To enable writing to a text file in admission scenario:

policy-agent:
config:
admission:
sinks:
fileSystemSink:
fileName: "file.json"

It is possible to make the file persistent using the following configuration. This assumes that there is a PersistentVolume already configured on the cluster.

policy-agent:
persistence:
enabled: false # specifies whether to use persistence or not
claimStorage: 1Gi # claim size
storageClassName: standard # k8s StorageClass name