I would like to create an API key which will give read-only access.
dan
October 25, 2024, 11:40am
2
No such thing at this time; it’s all or nothing. I believe there are plans to change this in future releases, but it isn’t there now.
truenas:master ← truenas:user-api-keys
opened 06:31PM - 25 Sep 24 UTC
The primary motivation for converting API keys so that they are explicitly linke… d to user accounts is to provide some method for TrueNAS Connect to use tie in to local or directory services accounts to a credential that is persistently stored in the TrueNAS Connect keychain.
The legacy API key mechanism was insufficient for this purpose because the mismatch between user accounts and API keys could lead to administrators retaining NAS access after account deletion, expiration, or locking. For more in-depth context and reasoning please refer to the internal design document NEP-053.
For this purpose, this commit makes the following changes:
1. Legacy API keys are migrated to a user_identifier LEGACY_API_KEY which is automatically linked to the root, admin, or truenas_admin account depending on server configuration.
2. If the legacy API key granted less than FULL_CONTROL, then the API key is migrated with a `revoked` state so that the system administrator has an opportunity to review and generate a new key and/or service account that provides the correct level of access.
3. API key authentication now passes through libpam.
4. user.query results now include an `api_keys` key that contains a list of IDs for API keys that exist for the user.
5. Authenticated users with READONLY_ADMIN privilege or greater are able to create and manage their own API keys.
During development of this new feature, it was determined that the original API keys were written with insufficient hashing rounds leading to the following changes:
6. On successful authentication the stored hash of any LEGACY_API_KEY is automatically upgraded to a newer sha512-based standard with significantly increased hashing rounds.
7. Dependency on the passlib library was removed.
Since libpam is now used for all non-token authentication methods, a new auth login endpoint (auth.login_ex) was added to middleware to facilitate future enhancements for challenge-response authentication mechanisms. Authentication via username + password + OTP token has been converted to this new standard. This new endpoint is more closely aligned with standards and requirements in NIST SP 800-63B. In summary the following changes were made:
8. An AuthentationContext dataclass was created to house a middleware session's PAM context and associated information. An instance of this is stored in the session's App object.
9. A new endpoint auth.login_ex was added that is expandable and is aware of the server's configured "authentication assurance level".
10. Existing login endpoints (auth.login, auth.login_with_api_key, auth.login_with_token) were converted to wrappers around auth.login_ex.
11. Initial implementation of session lifetime and inactivity guidelines for different authentication assurance levels was added.
12. Challenge-response workflow for username + password + OTP token implemented with associated tests.
In FangTooth (25.04) you will be able to create API keys for particular truenas user accounts that inherit whatever privileges are associated with the user account.
This means for readonly API access you would:
create service account (locked-down local user account)
grant service account relevant read-only API privileges
create API key for service account
Enterprise customers will be able to do (2) → (3) for existing AD / LDAP service accounts that should access the NAS.
1 Like
