Support validating host annotations for authentication while loading a policy

[InbalZilberman]

Is your feature request related to a problem? Please describe.

As a Conjur user I would like to fail in loading policy if I load a policy with wrong host annotations per authentication rules so that I will be able to fix them in advance and not in runtime (while trying to authenticate)

Describe the solution you would like

This applies to all authenticators that support host annotations :

• K8s authenticator - and its constraints
• Azure authenticator and its constraints step 3 in here
• GCP authenticator - here and here

Each authenticator has its own constraints and rules. If the mandatory host annotations are not provided then we should provide the user with a proper message like "host annotation subscription-id is missing. In order for the host to be authenticated with authn-azure please add this annotation." Similarly to errors we provide while authenticating with host with no mandatory host annotation.

Another use case: If the host annotations does not exists we need to raise it with a proper user message

please take into account host with several authenticators type

[moticless]

Time estimation

• General notes:

  • During policy loading we don’t know today which authenticator is supported. This is because our authenticator are not treated as true plugins components.

  • As part of this effort, we might find ourself trying refactor authenticators to become more pluggable. Such step will increase the effort.

• Design - 4

  • There is a long pending PR by Ofira that that suggest a generic infra-hook for validating policy: https://github.com/cyberark/conjur/pull/1794
  • Define the set of rules for each authenticator
  • Add infrastructure to enforce the set of rules over the loaded policy.
  • Need to verify that our design is aligned with architectural planning for pluggable/factory authenticator. To decide how far we want to go forward with it.
  • know how to catch partial configuration; conflicts; invalid-values

Hear-under we assume that no special refactor/factory is required.

• Implementation – 3

• Testing - 6

• Doc - 1

  • Changing behavior