AGENT-997: Internal dev docs for authentication-authorization #9224
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@pawanpinjarkar: This pull request references AGENT-997 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.18.0" version, but no target version was set. In response to this: Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
/cc @andfasano @rwsu |
|
@pawanpinjarkar: This pull request references AGENT-997 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.18.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
There was a problem hiding this comment.
Thanks @pawanpinjarkar for this doc, it will definitely help.
Apart the suggested changes it looks fine, but for a relevant point: the document jumps immediately in a pretty detailed/technical description, without providing to the reader a more gentle and high-level overview of how it works (and that could help understanding better the subsequent more detailed section).
For that it'd be useful to provide a couple of diagrams (mermaid could be a good fit for that) describing at a very high level how the tokens are generated / consumed (aka verified) for both day1 and day2 cases.
|
@pawanpinjarkar: This pull request references AGENT-997 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.19.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
@pawanpinjarkar: This pull request references AGENT-997 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.19.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
@pawanpinjarkar: This pull request references AGENT-997 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "4.19.0" version, but no target version was set. In response to this: Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
pawanpinjarkar
force-pushed
the
dev-docs-authentication-authorization
branch
from
c408842 to
5e0fbc6
Compare
|
|
||
| ## Tokens for Agent-Based Installer | ||
|
|
||
| When creating an Agent ISO (or PXE artifacts) for installing a new cluster, ABI generates three separate authentication tokens: `agentAuth`, `userAuth`, and `watcherAuth`. These tokens serve different purposes and have varying levels of access. The tokens are the part of the ignition that gets embeded in the CoreOS base ISO along with other ABI specific configurations for a cluster. The tokens are stored `/usr/local/share/assisted-service/assisted-service.env` in the ISO. The base64 encoded public key required to validate these tokens is also saved in the same file. Additionally, this data also gets stored in a hidden file `.openshift_state_install.json` present in the directory location mentioned when creating ISO. |
There was a problem hiding this comment.
| When creating an Agent ISO (or PXE artifacts) for installing a new cluster, ABI generates three separate authentication tokens: `agentAuth`, `userAuth`, and `watcherAuth`. These tokens serve different purposes and have varying levels of access. The tokens are the part of the ignition that gets embeded in the CoreOS base ISO along with other ABI specific configurations for a cluster. The tokens are stored `/usr/local/share/assisted-service/assisted-service.env` in the ISO. The base64 encoded public key required to validate these tokens is also saved in the same file. Additionally, this data also gets stored in a hidden file `.openshift_state_install.json` present in the directory location mentioned when creating ISO. | |
| When creating an Agent ISO (or PXE artifacts) for installing a new cluster, ABI generates three separate authentication tokens: `agentAuth`, `userAuth`, and `watcherAuth`. These tokens serve different purposes and have varying levels of access. The tokens are the part of the ignition that gets embeded in the CoreOS base ISO along with other ABI specific configurations for a cluster. The tokens are stored in `/usr/local/share/assisted-service/assisted-service.env` in the ISO. The base64 encoded public key required to validate these tokens is also saved in the same file. Additionally, this data also gets stored in a hidden file `.openshift_state_install.json` present in the directory location mentioned when creating ISO. |
Why is it stored in the hidden file?
There was a problem hiding this comment.
The tokens are part of the ignition and is also an asset hence those are saved in the hidden file .openshift_state_install.json like all the assets and other data.
| - installer | ||
| security: | ||
| - userAuth: [admin, read-only-admin, user] | ||
| - watcherAuth: [] |
There was a problem hiding this comment.
For watcherAuth, what does an empty array ([]) mean? Shouldn't there be something like read-only listed?
There was a problem hiding this comment.
The empty array under watcherAuth indicates that no specific roles are required—this is intentional and specific to the ABI flow. Unlike the roles mentioned for userAuth, which is tied to RHSSO auth type and uses IAM roles like admin, user, etc., ABI doesn’t use IAM policies. Instead, access control is based on the endpoint behavior itself.
For example, the watcherAuth persona (like the wait-for user) is only allowed to perform safe read-only actions like GET, while userAuth might have both GET and POST access, implying read-write. So the roles aren't declared because ABI evaluates access by persona and method, not by static role mapping.
|
|
||
| 1. The `auth_scheme` claim in the JWT token is extracted. | ||
| 2. If the claim is malformed or missing, an error is returned. | ||
| 3. The `auth_scheme` claim embedded in the token specifies the type of authorization (e.g., `watcherAuth`) and is compared with the `authScheme` expected by the endpoint. This ensures that the token matches the intended purpose of the request. |
There was a problem hiding this comment.
Is /v2/clusters above the only endpoint that supports watcherAuth?
There was a problem hiding this comment.
No, the full details are in the swagger.yaml here https://github.com/openshift/assisted-service/blob/master/swagger.yaml#L169
|
@pawanpinjarkar: The following tests failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
pawanpinjarkar
force-pushed
the
dev-docs-authentication-authorization
branch
from
1d624e7 to
395c8c2
Compare
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bfournie The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
bot
added
the
approved
|
/lgtm |
|
[ART PR BUILD NOTIFIER] Distgit: ose-installer |
|
[ART PR BUILD NOTIFIER] Distgit: ose-baremetal-installer |
|
[ART PR BUILD NOTIFIER] Distgit: ose-installer-artifacts |
No description provided.