Apikey config support

[rkustner]

As a jfrog SaaS user I want to be able to supply the API Key and some defaults to communicate with JFrog artifactory.

I created configJFrogAPIKey() in Utils.ts for this and added some parameters to action.yml. Will this work to be included in the main branch? I have it working similarly in a private action in our GitHub Enterprise organization.

I haven't tested if this still works with hosted JFrog server configuration.

• [ ] All tests passed. If this feature is not already covered by the tests, I added new tests.
• [X] I used npm run format for formatting the code before submitting the pull request.

---

[github-actions[bot]]

CLA Assistant Lite bot All contributors have signed the CLA ✍️

[rkustner]

I have read the CLA Document and I hereby sign the CLA

[rkustner]

recheckcla

[rkustner]

recheckcla

[eyalbe4]

@rkustner, Thanks for this contribution! I have a question though - what's the benefit of providing the URL, username and API key as independent arguments, vs. the existing functionality, which allows exporting the entire config (which includes the 3 arguments) and saving it as one secret?

[rkustner]

our use case is that we have multiple (automatically generated) jfrog API keys and Users which are stored as individual GitHub secrets. We want developers to be able to use those secrets in their own GitHub Actions workflow.

as far as I could tell based on the documentation, I couldn't find a way to use these API keys with the existing functionality.

maybe I misunderstand the current process of exporting the config as one secret, but I guess the differences between CLI versions and online documentation and examples makes it difficult. The server configuration as documented feels a lot like it's meant for selfhosted jfrog installations but we are using the JFrog SaaS solution

[eyalbe4]

Thanks for explaining this @rkustner.

I think however that you can achieve your goal with the existing functionality. The existing functionality even seems to make things easier. I would like us however to continue this conversation, because there's a chance I'm missing something in the flow you're describing. Here's what you can do with the existing functionality:

1. Every developer has his own API key - which is fine. All the developer needs to do, is to run the following commands on his local machine:

jfrog c add
jfrog c export <the server id>

(in the above "jfrog c add" command, the developer provides his own API key)

2. Save the generated token as a secret in his GitHub repository.

When a new API key is generated for the developer, he can always run this process again.

Looking forward to your feedback.

[rkustner]

our goal is to automate the process of secrets management and not put the responsibilty of generating and rotating keys in the hands of the developer. In our current design developers don't need to worry about secrets but just point to a generated github secret in their workflow. We also want to simplify this as much as possible for them so if we need to explain the process of creating and managing their keys too, that's time they need for coding their applications.

[eyalbe4]

I see @rkustner. And how do you automate the process of regenerating new API keys in Artifactory, and then storing them as secrets on GitHub? Do you have another action or workflow that runs periodically and handles that?

[rkustner]

We have build this automation in our own account vending machine using the GitHub API and JFrog API: GitHub API is used to store/rotate secrets JFrog API is used to create the artifactory repositories and API keys for each team currently developers use a private github action for the jfrog cli (which is a too many lines of code in the workflow for my taste... that's why it would be great it we could use the public jfrog cli action)

[eyalbe4]

Got it @rkustner. So I think we can take what you're doing to the next level, and make it even easier - here's what I suggest - We can add to the setup-jfrog-cli GitHub Action "API key and Access Token refresh functionality". It can work as follows - You'll still configure the server token as a secret, just like it is done today, but in addition to this, you'll be able to set the action to periodically refresh the API key or access token stored in the server token. The Action will read the stored token from the secret, refresh the API key or access token, and then save the updated token as a secret. All the refresh logic will be included in the setup-jfrog-cli Action. Let me know what you think about that.

[rkustner]

to create initial token, you would still need to follow the process of manually doing that on your computer or can this be automated through the JFrog API?

so the action will need to be able to manipulate the GitHub secret? how will it get permissions to do this?

[eyalbe4]

For your second question - i think that an Action can create secrets, but I haven't looked into this deeply. Being able to do this is a prerequisite of this solution.

And as for the first question - we can check if the secret exists already. If it does, it'll be updated with the new token. If not, the secret will be created, so no manual action is required, accept for the creation of the powerful token, that has permission to refresh tokens or regenerate API keys.

This is just an initial idea and there might be limitations to doing this. Let me know what you think.

[rkustner]

GitHub secrets in an Enterprise org are either in scope for the whole GitHub org or local to a specific repository.

The GitHub workflow will need permissions change the secrets. I don't think you can limit that to a certain secret, only to the repository if you use repository level secrets.

For compliancy reasons, we need to automate the creation and rotation of secrets. There should never be a need for a developer to handle a token or secret manually. We can handle this in our own code in the AWS Landingzone. Our code communicates with the GitHub and JFrog API's to manage GitHub secrets and JFrog API keys (and also to provision the JFrog artificatory repositories)

In the ideal situation, our developers would only need to put something like this in their work GitHub flow:

- uses: jfrog/setup-jfrog-cli@v1
  env:
    # what ever parmeters needed to give access to repository X in our jfrog SaaS installation.. probably coming from GitHub secrets
- run:
     # from here run any jfrog commands without the need to supply any parameters related to the connection

Currently, they need to checkout our modified version of the jfrog cli action coming from our private repo, which are a lot of lines of code to maintain. (This is also due to a limitation with GitHub and having a private GitHub action in a private org)

[davereid-pfg]

Our project is in a situation where we cannot use the config export/import secret functionality. We are provided with a Github secret for username and access token which is auto-rotated every 24 hours, so being able to use those in the 'with' parameters of the github action here makes a lot of sense to me, rather than us having to list the specific command to configure it.

I would prefer to be able to use these secrets in one wholistic step like this:

      - name: Install JFrog CLI
        uses: jfrog/setup-jfrog-cli@v2
        with:
          jfrog-url: 'http://www.example.com/'
          jfrog-api-user: ${{ secrets.ARTIFACTORY_USERNAME }}
          jfrog-api-token: ${{ secrets.ARTIFACTORY_TOKEN }}

Instead of having to do what we do now in two steps (but this works):

      - name: Install JFrog CLI
        uses: jfrog/setup-jfrog-cli@v2
      - name: Configure JFrog CLI
        run: jfrog config add default --url http://www.example.com/ --user ${{ secrets.ARTIFACTORY_USERNAME }} --access-token ${{ secrets.ARTIFACTORY_TOKEN }}

[sverdlov93]

HI @rkustner, @davereid-pfg, and @ldemailly, This PR is merged and adds the above functionality. Looking forward to your feedback on it. I will update this thread once the next release will be out.

[sverdlov93]

HI @rkustner, @davereid-pfg, and @ldemailly, Setup JFrog CLI 2.4.1 is released and includes the above feature. We'd appreciate your feedback on that.

[ldemailly]

Thank you! we'll give it a spin and get back to you!