Conjur supports resources which authenticate without an API key

[jvanderhoof]

Overview

The proposed solution for this is to introduce a new policy attribute for roles (e.g. host, user) called api_key_enabled. This attribute will default to true if not explicitly provided, and will dictate whether Conjur:

• Generates an API key when the role is created by policy:
  This is relevant for newly created roles. If api_key_enabled: false, then this role will never receive a randomly generated API key.

• Allows an API key to be rotated for a role:
  This prevents an API key from being created after the initial role creation.

• Allows an API key to be validated for a role:
  This covers the case when an existing role (that has an API key) is updated to set api_key_enabled to false. In this case the API key already exists, but the Role model will always return false for api_key_valid?.

Scenarios

Scenario	api_key_enabled: true	api_key_enabled: false
Role (host/user) created	API key is generated and stored in the database.	API key in the database is set to null.
Rotate role key	API key is rotated and new value is stored in database.	Value in database is unchanged and server responds with an error that keys are disabled for the role and cannot be rotated.
Default authentication authn	API in request is validated against key in database.	API key validation always returns false and authentication fails.
Update role to set api_key_enabled: true	No change	If key is null, generate value and store it in database.
Update role to set api_key_enabled: false	Set api key in DB to null	No change to database.

Prototype

Branches for prototype exploration for this proposal are available at:

• conjurinc/conjur-policy-parser
• cyberark/conjur

Areas not covered in prototype

• Error messages (specifically for CLI) when attempting to authenticate as a role that has no API key.
• Impact on docs for authenticators (to recommend adding this attribute).

Rough Effort Estimate

• Code Changes: 18 days
• Docs Updates: 8 days

[InbalZilberman]

@jvanderhoof thank you! a blessed change

1. I think that the error flows are very important for a comprehensive flows and UX. Can you please address maybe in highlevel how do you see these flows?
2. How are we keeping backward compatibility? How will this change affect DAP?
3. Have you considered having the same behavior as apps or clients? In addition or instead of the annotation?
   Making it explicit what users or hosts can authenticate using this authenticator?
4. Will authn stay enabled as today? why not provide it the same UX as any other authenticators?

[rafis3]

Regarding the UX of this feature, I wanted to propose that this indication would be in an annotation, like any other authentication we support. Something that would look like this:

- !host
  id: myhost
  annotations:
    authn/api-key: false

[szh]

This is implemented