Writing Policy Logic
Writing policies for jsPolicy generally means that you need to define two things:
- Policy Settings:
JsPolicy
specifies the type of policy and defines when this policy should apply - Policy Logic: Put the logic into the
spec.javascript
of aJsPolicy
or use a separateJsPolicyBundle
that contains the policy logic in the form of base64 encoded, compressed JavaScript code
#
Write Policy LogicThere are different ways to write policy logic for JsPolicy. The following table compares three common workflows:
Embedded spec.javascript | Separate JavaScript | TypeScript | |
---|---|---|---|
Language | JavaScript | JavaScript | TypeScript (modern) |
Type Safety | no | no | yes |
IDE Support | bad (JavaScript in YAML) | good | great (auto-completion, warnings, types) |
Testing | only end-to-end via test kubectl requests | unit, functional and end-to-end tests | unit, functional and end-to-end tests |
Publishing | only via JsPolicy YAML files | via npm packages | via npm packages |
JsBundle Generation | automatic by jsPolicy | manual or via dev tools (SDK) | manual or via dev tools (SDK) |
SDK | - | jsPolicy SDK | jsPolicy SDK |
#
Inline JavaScript PoliciesUse the spec.javascript
option of the JsPolicy
CRD to write policy code inline as embedded JavaScript ES5 (vanilla JS):
#
Dependencies For Embedded JavaScript PoliciesUse the spec.dependencies
option to define dependencies that you want to load for this policy. You can specify any CommonJS package from the npm registry here or import your own packages.
#
Separate JavaScript or TypeScriptYou can use a separate JavaScript project to build, test and deploy your policies. Any language that can get cross-compiled to Javascript is supported. Please take a look at our Policy SDK or TypeScript example on how to write policies and compile them to JsPolicy
and JsPolicyBundle
objects.