You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/how-to/manage-custom-policies-with-policyresourcemanager.md
+115Lines changed: 115 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -282,6 +282,121 @@ For **unit-targeted policies** (`PolicyTargetType.unit`):
282
282
Unit-targeted policies provide Layer 4 (TCP) access control to individual pods. They cannot restrict by HTTP methods, paths, or hosts - only by ports. This limitation comes from the underlying Istio service mesh implementation. Use unit policies when you need to access individual units directly, such as for metrics scraping from each pod.
283
283
```
284
284
285
+
## Using raw policy objects
286
+
287
+
For advanced use cases where `MeshPolicy` doesn't provide enough flexibility, you can pass pre-built policy objects directly to the `PolicyResourceManager` using the `raw_policies` parameter.
288
+
289
+
### When to use raw policies
290
+
291
+
Use `raw_policies` when you need:
292
+
- Mesh-specific features not exposed by the mesh-agnostic `MeshPolicy` abstraction
293
+
- Full control over the native policy specification
294
+
- Direct translation of existing mesh-specific policies to your charm
295
+
296
+
```{note}
297
+
`MeshPolicy` is designed to be mesh-agnostic. If your policy requirements are specific to a particular mesh implementation, `raw_policies` gives you direct access to the underlying policy format.
298
+
```
299
+
300
+
### Available policy types
301
+
302
+
Currently, the following raw policy types are supported:
303
+
304
+
**For Istio mesh:**
305
+
-`AuthorizationPolicy` - available from `lightkube_extensions.types`
306
+
307
+
### Building raw policies for Istio
308
+
309
+
Import the `AuthorizationPolicy` type and spec models:
310
+
311
+
```python
312
+
from lightkube.models.meta_v1 import ObjectMeta
313
+
from lightkube_extensions.types import AuthorizationPolicy
314
+
from charmed_service_mesh_helpers.models import (
315
+
AuthorizationPolicySpec,
316
+
From,
317
+
Operation,
318
+
PolicyTargetReference,
319
+
Rule,
320
+
Source,
321
+
To,
322
+
)
323
+
```
324
+
325
+
```{note}
326
+
The `AuthorizationPolicy` resource type is provided by `lightkube_extensions`, while the spec data models (`AuthorizationPolicySpec`, `Rule`, etc.) are provided by `charmed_service_mesh_helpers`. There are ongoing plans to consolidate the service mesh library offerings into a single, unified Python package.
327
+
```
328
+
329
+
Create an `AuthorizationPolicy` using the data models:
The `AuthorizationPolicySpec` is a Pydantic model. Use `.model_dump(by_alias=True, exclude_unset=True, exclude_none=True)` to convert it to the dict format expected by `AuthorizationPolicy.spec`.
376
+
```
377
+
378
+
### Reconciling raw policies
379
+
380
+
Pass `raw_policies` to `reconcile()` alongside or instead of `MeshPolicy` objects:
0 commit comments