Expand the REST API #1412
Comments
This new endpoint lives inside of the user namespace and its main goal is to allow people to create the first admin user from the API. This endpoint is only allowed if the `first_user_admin` option has not been disabled. Another restriction is that there shouldn't be a user already created. Last but not least, this method can be called without being authenticated. In the ideal case, you would call this method when you just started your Portus instance. Then, you will get the first user created (same arguments as `POST /api/v1/users`) and it will also get an application token assigned to it. The reponse will be the `plain_token` from the application token. Thus, the whole point of this method is to follow this workflow: 1. Portus instance deployed. 2. Admin uses this bootstrap endpoint to create the admin user and get an application token. 3. With this application token the admin starts to administrate the instance (e.g. register the registry on Portus) entirely from the API. 4. Admin makes the Portus instance available inside of the organization and starts structuring it inside of Portus. Finally, this commit also started to make error responses more uniform. This was firstly done to DRY some of the code created by this feature. It probably needs more work (see SUSE#1437). See SUSE#1412 Signed-off-by: Miquel Sabaté Solà <[email protected]>
This new endpoint lives inside of the user namespace and its main goal is to allow people to create the first admin user from the API. This endpoint is only allowed if the `first_user_admin` option has not been disabled. Another restriction is that there shouldn't be a user already created. Last but not least, this method can be called without being authenticated. In the ideal case, you would call this method when you just started your Portus instance. Then, you will get the first user created (same arguments as `POST /api/v1/users`) and it will also get an application token assigned to it. The reponse will be the `plain_token` from the application token. Thus, the whole point of this method is to follow this workflow: 1. Portus instance deployed. 2. Admin uses this bootstrap endpoint to create the admin user and get an application token. 3. With this application token the admin starts to administrate the instance (e.g. register the registry on Portus) entirely from the API. 4. Admin makes the Portus instance available inside of the organization and starts structuring it inside of Portus. Finally, this commit also started to make error responses more uniform. This was firstly done to DRY some of the code created by this feature. It probably needs more work (see SUSE#1437). See SUSE#1412 Signed-off-by: Miquel Sabaté Solà <[email protected]>
|
I know Portus syncs with the registry, but is there any way to sync another with portus? Say we wanted to know when an image got scanned and if vulns were found, mail someone... How can we do that without polling the whole catalog? |
I'm not sure I understood your question 😅 Please, correct me if I'm wrong. Right now Portus supports only one registry (see #821). So, if you are asking whether portus supports some kind of coordination between registries, then I'd say that it's not supported. If you are asking for some sort of coordination between multiple Portus registries, then I'd say we don't support that either. So I guess my question would be: what's your use case exactly ? What kind of workflow would work for you ? I'd say you can give these details into a new issue, because these questions are a bit out of the scope of this issue 😉 |
As understand it more correctly @mogul is referring to the webhooks functionality. Specifically triggering events on found vulns. |
Yes, that's exactly what I'm thinking of. Still out of scope and needing another issue? |
This new endpoint lives inside of the user namespace and its main goal is to allow people to create the first admin user from the API. This endpoint is only allowed if the `first_user_admin` option has not been disabled. Another restriction is that there shouldn't be a user already created. Last but not least, this method can be called without being authenticated. In the ideal case, you would call this method when you just started your Portus instance. Then, you will get the first user created (same arguments as `POST /api/v1/users`) and it will also get an application token assigned to it. The reponse will be the `plain_token` from the application token. Thus, the whole point of this method is to follow this workflow: 1. Portus instance deployed. 2. Admin uses this bootstrap endpoint to create the admin user and get an application token. 3. With this application token the admin starts to administrate the instance (e.g. register the registry on Portus) entirely from the API. 4. Admin makes the Portus instance available inside of the organization and starts structuring it inside of Portus. Finally, this commit also started to make error responses more uniform. This was firstly done to DRY some of the code created by this feature. It probably needs more work (see SUSE#1437). See SUSE#1412 Signed-off-by: Miquel Sabaté Solà <[email protected]>
This new endpoint lives inside of the user namespace and its main goal is to allow people to create the first admin user from the API. This endpoint is only allowed if the `first_user_admin` option has not been disabled. Another restriction is that there shouldn't be a user already created. Last but not least, this method can be called without being authenticated. In the ideal case, you would call this method when you just started your Portus instance. Then, you will get the first user created (same arguments as `POST /api/v1/users`) and it will also get an application token assigned to it. The reponse will be the `plain_token` from the application token. Thus, the whole point of this method is to follow this workflow: 1. Portus instance deployed. 2. Admin uses this bootstrap endpoint to create the admin user and get an application token. 3. With this application token the admin starts to administrate the instance (e.g. register the registry on Portus) entirely from the API. 4. Admin makes the Portus instance available inside of the organization and starts structuring it inside of Portus. Finally, this commit also started to make error responses more uniform. This was firstly done to DRY some of the code created by this feature. It probably needs more work (see SUSE#1437). See SUSE#1412 Signed-off-by: Miquel Sabaté Solà <[email protected]>
|
Why not using the Webhooks from Clair? (if you are using it as a scanner). https://coreos.com/clair/docs/latest/notifications.html - with the clair api you could scan the image BEFORE pushing it to the registry which works quite well |
|
@adnoh thanks for the heads up! I'll paste this comment into the other issue to keep everything on the same place. |
|
@mssola You're welcome. I've just went through the whole portus, postgres, clair, registry, kubernetes journey the last week - so I'm looking around if I can help anyone with current issues :) it was quite hard to get all the pieces working. |
|
@adnoh what do you mean by hard? What was hard for you ? Just asking in case we can improve the documentation or our examples 👍 |
|
This is an on-going effort. Scheduling for the 2.5 release... |
The text was updated successfully, but these errors were encountered: