Foreman Personal Access Tokens Inherit Broad Default Roles
Foreman Personal Access Tokens Inherit Broad Default Roles
Foreman administrators manage hosts, organizations, locations, and provisioning workflows. Personal access tokens provide API access without an interactive password. The token's authority comes from the user's roles and permission filters. A review that checks only token expiry can miss a default role that applies to every user in the system.
Start with the role graph
Foreman documentation defines roles as sets of permissions and permission filters. It notes that the Default role applies to every user and warns that adding a permission to that role grants it to all users.
Inventory predefined and custom roles, their permission filters, and the users or groups assigned to them. Pay particular attention to permissions that create personal access tokens, manage users, change settings, or administer organizations and locations. A user who can create a token for another identity may bypass the intended separation.
Use API-only users
Foreman documentation describes API-only users for automation. Create one for each integration and assign a narrow role. Do not let an API user inherit a human administrator's complete role set merely because it was created from a copied account.
Record the token owner, purpose, permissions, creation date, and rotation date. Store the token in a secret manager. Use the API's own permission checks in staging to prove that the account cannot modify hosts or settings outside the intended scope.
What the ZoomEye observation shows
The count-only queries used sub_type=all, page 1, and page size 1. app="Foreman" returned 3,339, title="Foreman" returned 692, and http.body="Foreman" returned 19,026.
The application count is larger than the title count, which can happen when the fingerprint identifies a service that does not use a uniform page title. The values are useful inventory observations, not proof of an exposed API or a default-role problem.
Use the result to compare owned and expected Foreman installations with DNS and certificate inventory. Do not attempt to authenticate against an unknown management service.
Review privilege filters
Permission filters can restrict a role to specific resource instances. Confirm that the filter matches the intended organization or location and that the user cannot select a different resource through an API parameter. Test list, show, create, update, and delete operations separately.
Review plugin permissions. A plugin may add API endpoints or resource types that are not covered by the original role review. Include plugin updates in the change process.
Revoke and verify
Delete a test token and confirm that the API rejects it. Remove a user from a role and test an existing token. If the token still has access, determine whether the role change requires a new session, a cache refresh, or a different revocation path.
Alert on token creation, role changes, user creation, organization changes, and host provisioning actions. Tie those events to approved change records.
Foreman's Default role makes a small permission change system-wide. Review it as a sensitive configuration object, not a convenience setting. The token inventory then describes who can use that authority and how quickly it can be withdrawn.