Our initial concept for this inventory of credentials.
The first draft of a prototype for the inventory.
Concept designed by @manojmj with backend considerations taken into account.
Working Concept Breakdown
Separate out the type of credentials in the view to make this feature more performant and future proof instead of loading all kinds of credentials in one single view.
Advantages:
Different types of credentials are stored in different tables in the db and hence to show all these credentials in a single view would mean that we'd have to query multiple tables at once and then sort them in memory (possibly).
A homogeneous list of items is much easier to sort and filter than a heterogeneous list.
The attributes in these tables also differ, eg: PAT has expiry and scopes but SSH does not. SSH has last_used_at but PAT does not and as far as I understand, it would mean a bunch of if..else statements to display this properly.
Separating out the different types of credentials scales - if we have to add a third kind of credential to the view, it'd be very easy.
We use a similar approach in /admin/users already, ie, tabs for Deactivated, Blocked users etc.
Default to Most Recent to Oldest sort order based on the "Last Used" column.
Users should be able to sort and filter to see desired data subsets.
Permissions and Security
Only Administrators should be able to view this.
This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Category:Fuzz Testing
GitLab Ultimate
devops
application security testing
feature flag
frontend
fuzzing
coverage
group
dynamic analysis
missed:14.7
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
missed:14.3
missed:14.4
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
@manojmj I've updated the issue description here to capture your work as I believe that will be the best path forward on this feature. Thanks again for the awesome work
@mattgonzales@dmoraBerlin do you mind if we change the mock a bit to make the owner user's details a bit more rich with avatar and name data? We can get this at no extra frontend effort too, since the partial already exists and we use it in admin/users page and we just have to reuse it.
It'd look like this:
Let me know if we'd prefer to just show the email data instead
100% I think this is much better. And since it's already part of the system then that would be best.
The initial mockup I made was simply a base to build off of. So any way we can expand it's "features" would be best. As I'm still new to GitLab I'm trying to connect all the components together.
This looks great! Let's work towards this as I think the additional detail would be helpful in quickly identifying users at a glance. I would propose we keep the name instead of just an email address.
Hi @mattgonzales, couple of questions that came up during implementation, could you please clarify?
Default ordering: PATs does not have last_used_at detail, shall we order by "most recently created first" instead just for PATs?
We have the concept of Impersonation access tokens, which is also a type of access token which can be only be created and by admins, but posing as a different user. This should be included in the list, right?
If we do include Impersonation tokens in the list, I feel it is important to highlight whether a token is an impersonation token or not, like this , is this okay?
We should include only include active personal access tokens in the list, and not revoked ones, right?
Sure, we can order by "most recently created first". Will PATs have last_used_at added with this feature? Or would that be a later iteration?
IATs should be included, yes, but we can probably save that for a later iteration. There's an issue somewhere (need to find again) that discusses adding impersonation events/detail to audit events. I think adding the IAT at that point might make sense. I'd like to better understand impersonation and it's impacts on an instance/auditing before I commit to adding it here
I agree with this proposal once we are ready to implement IATs, absolutely. Let's hold for now though until I can better understand the dynamics and implications.
Yep! I don't believe there's value in viewing revoked tokens, though I could be wrong. If customers request that, we can explore adding those in a future iteration.
@mattgonzales, awesome, thanks for answering so clearly!
Sure, we can order by "most recently created first". Will PATs have last_used_at added with this feature? Or would that be a later iteration?
We'd need to tackle this in a new issue, we do not store last_used_at of PATs currently and it will require significant effort to introduce this.
IATs should be included, yes, but we can probably save that for a later iteration. There's an issue somewhere (need to find again) that discusses adding impersonation events/detail to audit events. I think adding the IAT at that point might make sense. I'd like to better understand impersonation and it's impacts on an instance/auditing before I commit to adding it here
I agree with this proposal once we are ready to implement IATs, absolutely. Let's hold for now though until I can better understand the dynamics and implications.
Cool, I will remove the IAT changes I worked on, there wasn't much work done on it either way. I will stop showing IATs altogether in this page.
Yep! I don't believe there's value in viewing revoked tokens, though I could be wrong. If customers request that, we can explore adding those in a future iteration.
Cool, nothing to change here, I was already working under this assumption.
Thanks, I made changes to make this available only in Ultimate. I missed it in the beginning because it wasn't in the description, but then I noticed the labels in the sidebar