Treat API key as secret and store them securely

[rkg-mm]

Team API keys should be treated as a secret and not stored in plaintext, instead stored as and compared against the hash. They should not be available on UI like currently in Dependency-Track, except once when generating them. Instead they should get a name and only the name be displayed in UI, to allow identify & delete them.

[mum-viadee]

As already stated in DependencyTrack/dependency-track#2552 the API keys should definitely treated more securely. They should be generated for user accounts, not for teams. Having api keys for teams seems to me like a wrong architectural decision. An API key should belong to a single user. This is helpful for auditing actions in Dependency Track. A user shoud be able to generate an API key for himself. There could be technical accounts like CI users that only have API keys and no password at all. Hence loging in on the gui with a technical account would not be possible.
Teams should, at least from an Dependency Track kind of view, only containers for handling permissions in an RBAC way.

[rkg-mm]

As already stated in DependencyTrack/dependency-track#2552 the API keys should definitely treated more securely. They should be generated for user accounts, not for teams. Having api keys for teams seems to me like a wrong architectural decision. An API key should belong to a single user. This is helpful for auditing actions in Dependency Track. A user shoud be able to generate an API key for himself. There could be technical accounts like CI users that only have API keys and no password at all. Hence loging in on the gui with a technical account would not be possible. Teams should, at least from an Dependency Track kind of view, only containers for handling permissions in an RBAC way.

I see your point but would disagree here. It would drastically increase the effort if I needed a special account (managed by our IT in Active Directory) for each team. With many teams I would have to request from our IT an account every time a new project is set up. Since the team is unable to gain access to the Key by themselves, I don't see a problem. Ideally it would be visible which API key is used to do an action in the logs, and naming the API keys would be helpful too. But then I see no further benefit from using a separate user.

[mum-viadee]

In order to use tools such as the Dependency Track in a regulated environment like a financial institute , it is essential that actions can be assigned to a single, specific user. How useful is an audit trail (see Dependency Track) if it says that someone from a team of 50 people has signed a vulnerability as a false positive? It is practically useless.
Users should be able to generate API keys themselves. Like in GitHub, for example. There is no need for an administrator to create keys for users. Administrators shouldn't even see plaintext api keys of users.

[rkg-mm]

What if it says the API key named "build server" of team X has done it?.

I agree with the plaintext keys, thats my original request.

[rkg-mm]

So your workflow would be

1. set up team
2. set up CI-User and add to team
3. login as CI-user and create API key
4. Configure CI build with API key?

[mum-viadee]

So your workflow would be

1. set up team

2. set up CI-User and add to team

3. login as CI-user and create API key

4. Configure CI build with API key?

Almost, Maybe an administrator could create this ci-user as a technical user without password, generate an api key and stores this key in the configuration of the CI-server. The api key should only be visible to the administrator once he created it.

[mum-viadee]

You just can't enforce non repudiation, if api keys are generated for teams.

[Gepardgame]

Almost, Maybe an administrator could create this ci-user as a technical user without password, generate an api key and stores this key in the configuration of the CI-server. The api key should only be visible to the administrator once he created it.

But that would require an Admin to generate an user for every project. That could go for big companies into the ten thousands. Yeah, you could share this user between projects, but then again it is used for more things. Either way only admins should have access to the key, even though its a team key.
I agree that API keys for user would be useful, maybe even implement it such a way, that you can easily use it for other things such as projects, but in my opinion delting it for teams is not that useful.

Maybe it would be even useful, that api keys can do certain things based on permission it should have. So you have one Key only for CI uploads, but nothing else. That way it can't be misused so easily.

[rkg-mm]

Maybe it would be even useful, that api keys can do certain things based on permission it should have. So you have one Key only for CI uploads, but nothing else. That way it can't be misused so easily.

This would actually be a useful enhancement. usually keys are used for e.g. pipelines and need the project scope of the team, but only permissions to e.g. create projects and upload sboms, maybe modify project tags. So if a key can be scoped in permissions this would be great.

I also agree with, creating users is a lot of overhead and no benefit:

1. Creation: If only the creator sees the key, and the audit log states who created a key, you know who initially had it. If the admin instead creates a service user, creates then a key for the service user, you have the same information at this point of time.
2. Sharing: Afterwards, in both cases, the key will be either shared or at least stored in e.g. pipeline secrets (which are always extractable for anyone able to modify pipelines). So the audience knowing the key will be identical again.
3. Usage: I'm not sure if the audit log shows an identifier of the used api key or the user doing an action. If this is given (actions are linked to key if used or linked to user if done from user login) we have again identical information from an audit perspective, in both cases.

So we see, there would be no benefit of the user overhead. If 3) is not yet the case, THIS should be the enhancement we should do, which does not increase management effort but achieves the same goal.

[mum-viadee]

If users could generate api keys for themselves, there would be no need for an administrator to create them.

There are two scenarios I can imagine:

1. A technical user for a CI system is needed. So an administrator will create one user, adds this user to the team and creates a singel api key for this technical user in the CI system. The permissions of the technical user could be scoped as needed for sbom uploads, etc..

2. User use the REST API to automate things. This could be tasks like suppressing vulnerabilities in a huge amount of small projects, like microservices that share the same technological base. In this scenario every user could generate a api key for himself and use this key. If logging would work correctly with the REST API, the correct user would be logged for the calls. Unfortunately, this is currently not the case.

[rkg-mm]

@mum-viadee can you explain the benefit of 1), taking into consideration what I wrote about this? Maybe I don't see it yet. I only see 2 drawbacks:

1. I need to create a new user and manage that for every team
2. I need to manage (and keep in sync) a second team for every team, as he needs the same project scope but different permissions.

I understand your second use case, there user API tokens would make sense.

[mum-viadee]

@rkg-mm I don't understand your use case. Why do you need an api key for every team? Does every team has his own CI server? We have one technical user that is used for all teams to upload the sboms, it has permissions to upload sboms for every project in our dependency track instance. The different project teams can work only on projects they have permissions on.

In your scenario a team meamber could generate an api key for his team using his account and even share the key with team members if he wants to. No need for an administrator. Sharing the key has to be done outside of the dependency track, which is the only difference than having a shared key for a team.

[Gepardgame]

We have one technical user that is used for all teams to upload the sboms, it has permissions to upload sboms for every project in our dependency track instance.

But wouldn't it be easily possibly to upload things to a project, there I have no access to.

In your scenario a team meamber could generate an api key for his team using his account and even share the key with team members if he wants to.

But then the Key has access not only to this team or projects the team belong, but to all projects from the user, there their shouldn't have. Yet again if he shares it is the same problem with repudiation, as you don't know how used it. No difference if it comes from the user or a team.

My suggestion would be that both teams and user can create API Keys, which can have different permissions for different use cases, and then let the users decide which one they want to use, as both have good use cases.

[mum-viadee]

Yet again if he shares it is the same problem with repudiation, as you don't know how used it.

I agree, sharing a key brings problems with the reputation. But thats a decision of the user that shares the key. By now there is no such decission.

But wouldn't it be easily possibly to upload things to a project, there I have no access to.

Only the CI system should have the secret api key and can upload sboms. It must be prevented in that system, that you spoof uploads.

[Gepardgame]

I agree, sharing a key brings problems with the reputation. But thats a decision of the user that shares the key. By now there is no such decission.

How do you mean there is no such decision? As far as a know only admins can see the api key in the admin panel. Same know he has the decision to share it.

Only the CI system should have the secret api key and can upload sboms. It must be prevented in that system, that you spoof uploads.

So on your system its not possibly to write a own pipeline? When I have this possibility I can just upload a sbom in there to a different project. In the same/similar way as you would upload to your project.

[mum-viadee]

Hi @Gepardgame,
the key itself is, as by now, shared for the whole team. There is no chance to make someone accountable for things done with the key. In my second scenario (REST API used to automate things) you cannot enforce reputation. That is the missing decission I ment.

In our ecosystem it is possible to write a own pipeline. And yes, you could potentially upload an sbom for another project. That's a risk, we can live with. As all our projects regularly upload their sboms, you would have to regularly overwrite these sboms. And with the configured notifications, it would be strange that a finding reappears ervery once in a while.

We want to automate the creation of suppressions for findings and other things by using the rest api. Here we need to know who has created the suprression.

So it looks as if we need both. API keys for teams as a shortcut for technical users, which would have to be created for each team, and secondly, API keys for individual users, so that you can also ensure reputation if necessary.

[Gepardgame]

the key itself is, as by now, shared for the whole team.

Do you know there in the code? I only found an indirect way, over getting /v1/user/self, as this returns also the teams your part of. But normally API Keys can only be get from a admin (ACCESS_MANAGEMENT).

So it would be very useful like that:

1. can have teams as well as users (Maybe implement it more generic, so you could say I want a Key for a project (Gitlab overs that to) or something else)
2. has permissions, so key 1 can only be used to upload sboms and key 2 can used for something different, but are from the same user / team
3. I would also implement it, then API is stored as a hash it shouldn't be returned at all anymore, as it is the case now. So you can see it only once at creation and then not again. Many sites have it implemented that way.

Sounds that reasonably to you? The good thing is also, that you don't need to use all feature, but only those you need.

[rkg-mm]

@rkg-mm I don't understand your use case. Why do you need an api key for every team? Does every team has his own CI server? We have one technical user that is used for all teams to upload the sboms, it has permissions to upload sboms for every project in our dependency track instance. The different project teams can work only on projects they have permissions on.

In your scenario a team meamber could generate an api key for his team using his account and even share the key with team members if he wants to. No need for an administrator. Sharing the key has to be done outside of the dependency track, which is the only difference than having a shared key for a team.

We are no classic software vendor, but a software & digitalization partner. We create usually software as contractor for customers. For this we have different environments for every customer (usually a separate DevOps organization per customer, sometimes even work in a customer provided environment). Customers often have access to this environment. So we need to strictly separate everything between customers (sometimes even within multiple projects per customer), hence, each team gets their own API key, so the build environment only has access to the projects of this team.

Sharing the key has to be done outside of the dependency track, which is the only difference than having a shared key for a team.

That is the intended case, currently DTrack only is intended to show the keys admins. However, in my opinion not even that should be the case after creation.

[Gepardgame]

1. can have teams as well as users (Maybe implement it more generic, so you could say I want a Key for a project (Gitlab overs that to) or something else)
2. has permissions, so key 1 can only be used to upload sboms and key 2 can used for something different, but are from the same user / team
3. I would also implement it, then API is stored as a hash it shouldn't be returned at all anymore, as it is the case now. So you can see it only once at creation and then not again. Many sites have it implemented that way.

@nscuro Are you ok with the specs?