Comments (7)
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.
from alpine.
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.
from alpine.
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.
from alpine.
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.
from alpine.
So your workflow would be
- set up team
- set up CI-User and add to team
- login as CI-user and create API key
- Configure CI build with API key?
from alpine.
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.
from alpine.
You just can't enforce non repudiation, if api keys are generated for teams.
from alpine.
Related Issues (20)
- Update to Java 17 HOT 4
- Migrate to Jakarta EE namespace HOT 3
- Add an OIDC default group HOT 1
- Add description field to ApiKey
- Save and load `SecretKey` using encoded byte array instead of Java Object Serialization
- Add getTeams() to Principal contract
- Add support for multiple OIDC providers
- Use new class ProxyConfig for proxy selection in OIDC configuration
- Update JUnit 4 to 5 using OpenRewrite
- Log IP / User Agent for invalid ApiKeys and JWTs
- Provide a means to disable or otherwise configure the DataNucleus L2 cache
- Use USERS_SEARCH_FILTER to search for LDAP User
- Add ability to customize the Micrometer `MeterRegistry`
- Add support for logging in JSON format
- Add dynamic JWT Token expiry time
- Add 'comment' field for API keys HOT 2
- Upgrade Surefire Plugin from 2.22.2 to Latest 3.x
- Please publish alpine-parent before dependency-track
- Investigate datanucleus issue where storeMgr is null HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from alpine.