default router policies unless init --no-router-policies

[qrkourier]

Everyone who learns how to Ziti stumbles immediately on the fact that the controller does not automatically create a blanket, default ERP, and SERP.

A controller, when initializing, should always do the equivalent of these two commands unless the --no-router-policies flag is set.

ziti edge create edge-router-policy "all-routers" \
    --edge-router-roles '#all' --identity-roles '#all'

ziti edge create service-edge-router-policy "all-routers" \
    --edge-router-roles '#all' --service-roles '#all'

[ekoby]

I'd certainly prefer that quickstart created usable policies.

another option is when creating a service to check if it is accessible/usable and output a message with commands to configure policies. Something like this:

$ ziti edge create service super-service ...
...
Service `super-service` need policies to be accessible, here is how you can create them:

    ziti edge create service-policy ...
    ziti edge create service-edge-router-policy ...

[qrkourier]

Relevant console issue: openziti/ziti-console#181

[qrkourier]

I'd certainly prefer that quickstart created usable policies.

@ekoby You'd prefer default policies or referring users who want default policies to the quickstart? Not sure if "prefer that quickstart created" or "prefer that over quickstart-created."

[qrkourier]

@ekoby Now it seems obvious, and I agree that quickstarts should create default policies. ziti edge quickstart and its Docker and Kubernetes counterparts already do this. ☺️

[dovholuknf]

With the new "deployments" (aka prod-type), the question to me is, should THOSE do this sort of thing too? I think it's clear that the user should be prompted during intstall that some bootstrapping type script can optionally insert the policies. Kubernetes and docker are harder to do this in. Those should probably output a banner after running, showing the user exactly what to run next if they want default policies and that we STRONGLY recommend them. or something like that. i don't think unattended installations need any sort of 'option' though, there shouldn't be some env var saying "BOOTSTRAP_POLICIES" - the automation should just know it's needed and do it and that should be left up to the operator

[qrkourier]

Still, many new users face a broader friction point: services don't work until they determine they need router policies. This is pointless friction because most users will never need anything more granular than permissive default router policies.

This leads me to the two implementation alternatives that have surfaced up to this point.

1. Let ziti controller init create default router policies. I prefer that it does this by default and offers a flag like --no-router-policies to disable the default behavior. This is minimal and simple.
2. A more generalized solution to orchestrating Ziti entities would be a Terraform-esque declarative interface that reflects the API model. This will allow the controller to reconcile the declared entities with actual entities during startup. Declared entities should be "system managed" and therefore immune to management API CRUD.

Here's a hypothetical immutable.yml in the same dir as controller's config.yml.

immutableEntities:
   - name: default
      type: edge-router-policy
      edge-router-roles: public
      identity-roles: all
    - name: default
      type: service-edge-router-policy
      edge-router-roles: all
      service-roles: all

This file is configured in the controller's config.yml like this. The immutableEntities is an ordered list with a well-defined precedence and may include additional files or directly declare entities.

immutableEntities:
  - include: ./immutable.yml

[qrkourier]

The consensus is prod deployments shall never create default router policies. Quickstarts already create default router policies.