There is a new endpoint for creating an authenticator instance in policy

[izgeri]

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

At current, most Conjur authenticators require end users to load some boilerplate policy to set up the authenticator for use. For example, in the authenticator design we minimally require there is a webservice defined in Conjur policy in a specific conjur/{authenticator}/{service_id} policy branch.

Loading this policy can be cumbersome, and manual transcription and permission errors are easy to make. In this issue, I propose adding a new endpoint that can automatically load this policy for end users.

Describe the solution you would like

I propose we create a new route

put '/:authenticator/:service_id/:account' => 'authenticate#create

The OpenAPI definition of the route would be:

    EnableAuthenticatorInstance:
      put:
        tags:
        - "configuration"
        summary: "Creates authenticator service instances."
        description: "Allows you to create an authenticator service instance.
        
          When you create an authenticator service instance via this
          endpoint, the policy to define the webservice and the consumers group
          with `read` and `authenticate` permissions on the webservice are
          automatically created in policy in the `conjur/{authenticator}/{service_id}`
          policy branch."
        operationId: "createAuthenticatorInstance"
        parameters:
        - name: "authenticator"
          in: "path"
          description: "The authenticator to update"
          required: true
          schema:
            $ref: '#/components/schemas/ServiceAuthenticators'
          example: "authn-oidc"
        - name: "service_id"
          in: "path"
          description: "URL-encoded service id of the authenticator"
          required: true
          schema:
            type: string
          example: "prod/gke"
        - name: "account"
          in: "path"
          description: "Organization account name"
          required: true
          schema:
            type: string
          example: "default"

        responses:
          "200":
            description: "The authenticator service instance already exists"
          "201":
            description: "The authenticator service instance was created properly"
          "400":
            $ref: 'openapi.yml#/components/responses/BadRequest'
          "401":
            $ref: 'openapi.yml#/components/responses/UnauthorizedError'
        requestBody:
          description: "Optional additional key-value pairs for creating the authenticator service instance"
          required: false
          content:
            application/x-www-form-urlencoded:
              schema:
                type: object

        security:
          - conjurAuth: []

For example, for the Kubernetes authenticator a PUT request to /authn-k8s/my-k8s-service/default would load the following policy:

  - !policy
    id: conjur/authn-k8s/my-k8s-service
    body:

    # vars for ocp/k8s api url & access creds
    - !variable kubernetes/service-account-token
    - !variable kubernetes/ca-cert
    - !variable kubernetes/api-url

    # vars for CA for this authenticator ID
    - !variable ca/cert
    - !variable ca/key

    - !webservice
        
    - !host
      id: validator
      annotations:
        description: Validation host used when configuring a cluster
        authn-k8s/namespace: cyberark-conjur

    # Hosts that can authenticate become members of the
    # `consumers` group.
    - !group consumers

    # Ensure the validation host is part of the consumers group
    - !grant
      role: !group consumers
      member: !host validator

    # Grant consumers group role authentication privileges
    - !permit
      role: !group consumers
      privilege: [ read, authenticate ]
      resource: !webservice

If the request body included keys kubernetes/service-account-token, kubernetes/ca-cert, and kubernetes/api-url (most likely with base64-encoded values required), the variable values for these would be set after the policy is loaded. If the request body included the key conjur-namespace, its value would replace the value of the validator host's authn-k8s/namespace annotation.

Describe alternatives you have considered

n/a

Additional context

It would be nice if the policy could be validated with the platform / service after it's loaded - is it a valid policy? This may be too complex in practice, however; and the server loading the policy may not be the server that's handling authentication requests.