Lesson 16: Declarative ASM Policies and a Reviewable Automation Workflow

F5 ASM CLASSROOM • LESSON 16

Level: Advanced  |  Suggested study and lab time: 90 minutes
Instructor: Harpreet Singh Virdi, CISSP, CCSP

Start Here / Course Guide · All lessons

---

Make policy changes explainable

As environments grow, repeated manual edits become difficult to compare and reproduce. A declarative approach describes the desired policy in a structured file. The deployment process then applies that definition through a supported mechanism.

Declarative policy support, schemas, properties, and import methods vary by BIG-IP version. Use the schema and examples supplied for your target release. Do not copy a JSON example from a different product and assume it is valid ASM policy syntax.

Four parts of a useful workflow

• Source: a versioned policy definition and its dependencies.
• Review: a readable difference explaining what behavior changes.
• Validation: syntax/schema checks plus application regression tests.
• Deployment: authenticated application of the approved artifact, followed by verification and a recovery path.

Automation does not decide whether a new exception is justified. It makes the intended change easier to review and repeat. A syntactically valid file can still describe an overly permissive policy.

Guided lab

1. Choose a supported declarative template for your installed release.
2. Keep it in a private version-control repository with a README naming the target version and deployment method.
3. Create a minimal lab policy from the documented template. Keep secrets, tokens, customer requests, and sensitive exports out of source control.
4. Validate with the supported schema/tooling for that release.
5. Import or deploy it as a new lab policy. Inspect warnings, resulting settings, and policy state.
6. Associate it with lab traffic and run your positive and negative regression pack.
7. Change one scoped input constraint and review the file difference before redeploying.
8. Restore the previous artifact and demonstrate rollback.

Expected result: you can connect a repository revision to the deployed policy and test evidence. A pipeline marked green is not enough if it only checks that an API returned success.

A conceptual pipeline

Proposed policy change
  → peer review and schema validation
  → deploy to isolated lab
  → valid and invalid traffic tests
  → compare effective policy and review results
  → approved production deployment
  → service and enforcement verification

This is a workflow diagram, not a vendor-specific command sequence. Use the authenticated API or import tooling supported for your environment, with proper certificate validation and limited deployment permissions.

Watch for drift

Drift occurs when the running policy differs from the intended source. Decide how emergency GUI changes are documented and brought back into source control. Otherwise, the next automated deployment may silently replace a justified emergency fix.

Store custom signatures and other required dependencies through an approved mechanism, and check compatibility before upgrades. A policy file without its dependencies may not reproduce the behavior you tested.

Knowledge check

Why should an automated deployment inspect the effective policy after import?

Instructor answer

Unsupported properties, defaults, dependencies, or import behavior can produce a result different from the author's intent. Verify the actual deployed state and observable behavior.

---

Further reading

• F5 documentation: declarative policy getting started
• F5 documentation: maintaining security policies

Independent educational material. Menus, defaults, and feature availability vary by BIG-IP release and license. Use the documentation for your installed version. Perform exercises only in your authorized lab. Examples and expected results are instructional; these labs have not been executed on a BIG-IP device for this blog.

← Previous lesson · Course guide · Next lesson →