You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Most use cases for Heimdall (especially pipeline integrations via the API) can benefit from having a team as a logical unit for role-based access control (RBAC) purposes. For example, a app's CI/CD pipeline should be able to push scan outputs to Heimdall with an API key associated with the entire dev team to make scan content available to all developers without the scan ownership being tied to a particular user.
What is needed:
Group accounts
An API key (aka Token) for a group account (we can call it Services_Account) that can be used to curl scan content into Heilmdall.
Be able to create a Group API key programmatically as the owner of the group
Be able to create a Group API key via the GUI as the owner of the group
A way to designate in Heimdall that the evaluation (results file) is associated with a particular user or group
Users assigned to this Group Account can upload content to Heimdall without having to use their persona (aka user token).
Upon removal (deleting) of the Group, all associated users access is removed.
What needs to be done
Find out how tokens are generated for individual users
Repeat thee process for Groups such that they can have an API Key (aka token)
Verify that all users assigned to this Group can upload (curl) content to Heimdall on the Group behalf
How to verify it is done
A Group account exists such that an API Key can be generated for it.
Users can be associated with said Group Account.
Users associated with said Group Account can upload content to Heimdall utilizing the Group Account API Key.
--- Additional Comments and Notes ---
Major Use-Case is:
As a pipeline developer, we would like a service-level token (aka group account token) that is used as:
• Service-level on the server side (is implemented on the server-side)
• As a service account (automated pipelines runners)
• Access to view reports from everywhere
SERVICE GROUP
Ex: View reports from multiple groups (e.g. Supergroup A has access to Groups 1, 3, 5, 6)
GROUP
1 Pipeline pushes reports to Heimdall via API for only users of a Group to view (most use cases)
2 Pipeline pushes reports to Heimdall via API for all authenticated users to view
3 Show that data originated from a pipeline associated with a particular Group
4 Create a group via the GUI
5* Be able to create a group programmatically
6 Manage groups by cleaning up and removing data for groups that are no longer needed - If the group is deleted and users are still in the system, any user associated with that group would no longer have access to dashboards or data
7 Group is associated with the owner of the group (rather than NPE)
As a pipeline developer, we would like a group-level token
• (Maybe private and public distinction here fits the above use case)
• One or more users
Manager
The text was updated successfully, but these errors were encountered:
georgedias
changed the title
Allow for team ownership of files/interactiosn with API
Allow for team ownership of files/interactions with API
Nov 9, 2022
Most use cases for Heimdall (especially pipeline integrations via the API) can benefit from having a team as a logical unit for role-based access control (RBAC) purposes. For example, a app's CI/CD pipeline should be able to push scan outputs to Heimdall with an API key associated with the entire dev team to make scan content available to all developers without the scan ownership being tied to a particular user.
What is needed:
What needs to be done
How to verify it is done
--- Additional Comments and Notes ---
Major Use-Case is:
As a pipeline developer, we would like a service-level token (aka group account token) that is used as:
• Service-level on the server side (is implemented on the server-side)
• As a service account (automated pipelines runners)
• Access to view reports from everywhere
SERVICE GROUP
Ex: View reports from multiple groups (e.g. Supergroup A has access to Groups 1, 3, 5, 6)
GROUP
1 Pipeline pushes reports to Heimdall via API for only users of a Group to view (most use cases)
2 Pipeline pushes reports to Heimdall via API for all authenticated users to view
3 Show that data originated from a pipeline associated with a particular Group
4 Create a group via the GUI
5* Be able to create a group programmatically
6 Manage groups by cleaning up and removing data for groups that are no longer needed - If the group is deleted and users are still in the system, any user associated with that group would no longer have access to dashboards or data
7 Group is associated with the owner of the group (rather than NPE)
As a pipeline developer, we would like a group-level token
• (Maybe private and public distinction here fits the above use case)
• One or more users
Manager
The text was updated successfully, but these errors were encountered: