Authentication and Authorization Scenarios Enumerated for Helm¶
The discussion of JWKS and OPA in Helm outlines various
possibilities and invites the user to draw elements from different sections in
values.yaml file. With less contextual information, here we
enumerate various useful kinds of Helm chart in full:
OIDC and OPA: authentication and access control¶
- OIDC establishes a user's identity and provides Chronicle with information relating to the user's roles or authorization, perhaps via OAuth scopes.
- Chronicle uses OPA to consider if the user's OIDC-verified identity and roles allow them to perform the requested operation.
One variant of the above is when a JWT provided by the user already contains
all the claims that are needed. In this case, the
userinfo: section may be
omitted. Similarly, if the claims determining Chronicle identity are
id: can also be omitted as those are the default. To also allow
anonymous requests, without an
Authorization: header, also omit
Note: By default, if
auth.userinfo.url is provided,
required. To learn more about testing with Helm and default settings, see
this Note on Default Settings.
OIDC but not OPA: allow everything, recording identity¶
Chronicle can record who performed transactions while permitting them all:
OPA but not OIDC: universally restrict kinds of requests¶
Chronicle can enforce access control policies based on what the request is regardless of who the requesting user is:
Neither OIDC nor OPA: any controls are wholly external¶
If access to Chronicle's API does not need to be controlled by Chronicle itself, nor does the identity of requesting users need to be recorded with transactions, both OIDC and OPA may be disabled for the Helm installation:
Mock OIDC Server¶
Chronicle provides a mock OIDC server that can be used for simple testing.
In this configuration, Chronicle uses a mock OIDC server. See discussion.
You may instead choose to disable OPA with,
For more on Chronicle Helm testing scenarios, see our documentation on Helm Testing Scenarios.