Skip to content

Latest commit

 

History

History
130 lines (73 loc) · 6.9 KB

POLICIES.md

File metadata and controls

130 lines (73 loc) · 6.9 KB
Raw

VMware Tanzu Application Service > Butler

Managing policies

Creation and deletion of policies are managed via API endpoints by default. When an audit trail is important to you, you may opt to set cf.policies.git.uri -- this property specifies the location of the repository that contains policy files in JSON format.

When you do this, you shift the lifecycle management of policies to Git. You will have to specify additional configuration, like

  • cf.policies.git.commit the commit id to pull from
    • if this property is missing the latest commit will be used
  • cf.policies.git.filePaths an array of file paths of policy files

If you want to work with a private repository, then you will have to specify

  • cf.policies.git.username
  • cf.policies.git.password

one or both are used to authenticate. In the case where you may have configured a personal access token, set cf.policies.git.username equal to the value of the token.

A sample Github repository exists here.

Have a look at secrets.pws.json for an example of how to configure secrets for deployment of cf-butler to TAS integrating with the aforementioned sample Github repository.

On startup cf-butler will read files from the repo and cache in a database. Each policy's id will be set to the commit id.

Application and Service Instance Policies

Policy files must adhere to a naming convention where:

See additional property requirements in this sample Github repository.

Hygiene Policies

Hygiene policies are useful when you want to search for and report on dormant workloads, notifying both the operator and for each workload the author and/or his/her space compadres. Workloads are running applications and service instances that have not been updated in N or more days from the date/time of the policy execution.

Note: hygiene policy configuration has a special case where if the days-since-last-update property value is set to -1 then ALL workloads (minus the blacklist) are included in the respective notifications.

As mentioned previously the policy file must adhere to a naming convention

  • a filename ending with -HP.json encapsulates an individual HygienePolicy

See additional property requirements in this sample Github repository.

Legacy Policies

Legacy policies are useful when you want to search for and report on applications deployed to a legacy stack (e.g., windows2012R2, cflinuxfs2) or service offering (e.g., using a product slug name like p-config-server, p-service-registry, p-mysql), notifying both the operator and for each application, users with the space developer role.

As mentioned previously the policy file must adhere to a naming convention

  • a filename ending with -LP.json encapsulates an individual LegacyPolicy

See additional property requirements in this sample Github repository.

Resource Notification Policies

Resource Notification policies are useful when you want to generate a report containing resources of a particular type and send that report to email recipients identified by one or more label values ascribed to the those resources.

For example, you might notify primary and/or secondary owners of a collection of a resources.

As mentioned previously the policy file must adhere to a naming convention

See additional property requirements in this sample Github repository.

Endpoint Policies

Endpoint policies are useful when you want to exercise any of the available GET endpoints and have the results sent to one or more designated email recipients.

As mentioned previously the policy file must adhere to a naming convention

  • a filename ending with -EP.json encapsulates an individual EndpointPolicy

See additional property requirements in this sample Github repository.

Query policies

Query policies are useful when you want to step out side the canned snapshot reporting capabilities and leverage the underlying schema to author one or more of your own queries and have the results delivered as comma-separated value attachments.

As mentioned previously the policy file must adhere to a naming convention

  • a filename ending with -QP.json encapsulates an individual QueryPolicy

Reporting and notification oriented policies

If you intend to deploy endpoint, hygiene, legacy, query or resource notification policies, you must also configure the notification.engine property. You can define it in your

application-{env}.yml

notification:
  engine: <engine>

or

secrets-{env}.json

  "NOTIFICATION_ENGINE": "<engine>"

Replace <engine> above with one of either java-mail, or sendgrid

Furthermore, you will need to define additional properties depending on which engine you chose. Checkout application.yml to get to know what they are.

E.g, if you intended to use sendgrid as your email notification engine then your secrets-{env}.yml might contain

  "NOTIFICATION_ENGINE": "sendgrid",
  "SENDGRID_API-KEY": "replace_me"

Each reporting and notification oriented policy requires definition of an email notification template as part of its configuration.