Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.

If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!

Package Promotion via API with two restricted feeds



  • Hi,

    we are trying to incorporate the package promotion feature into our workflow and would like to use the API endpoint for that. Our scenario imposes the following requirements:

    • Both the source and target feed should be restricted to specific API-Keys only (i.e., we cannot allow anonymous access).
    • Furthermore, both feeds are in a feed group which also contains various other feeds. We use this feed group for other permissions, and thus cannot move the two feeds to another group.
    • Since the package promotion should be triggered in a CI environment, we cannot use impersonated api-keys.

    It seems that it is only possible to specify a single API-key for the package promotion endpoint. Thus, we cannot use a feed-specific API-key for the promotion. We therefore need to create a key for the whole feed group with both read and promotion permissions. Unfortunately, this key now has too much permission than actually needed, because it can also access the other feeds in the group.

    Is there anything I'm missing or something that we could do differently? We really would like to adhere to the principle of least privilege for those feeds, i.e. not giving the API-Key far more permissions than it needs. If that's not possible currently, are there any plans to a) either allow a feed to be in multiple groups, b) give the promotion endpoint the possibility to have two different API-keys, or c) define the permissions for an api-key more fine-grained?


  • inedo-engineer

    Hi @zs-dahe ,

    The Package Promotion API only be checks for permission against toFeed - you don't need any other permission on the toFeed or fromFeed.

    As far as more granular permissions, perhaps setting up a Personal Key for like a builds user would do the trick? That'll let you reuse the API Key and set up very granular permissions.

    We decided not to duplicate that granular permission setting in the API Keys because it's already confusing enough 🙄

    Thanks,
    Alex


Log in to reply
 

Inedo Website HomeSupport HomeCode of ConductForums GuideDocumentation