Suggestions to Optimally Manage/Refresh Secrets in Forge?

Forge
, , ,
1

I am building a solution which will require me to store secrets in my Forge application. Specifically, I will need to have the application use an API token which may be refreshed every X number of days.

I am thinking of using Forge’s encrypted storage to store the credentials. However, if I go this route I will likely need to build a UI to allow a user to set/initialize the token, then use the UI to update it for any future refreshes. If I did this, I would need to somehow lock down the UI to prevent any non-admin users from messing around with this part of the UI.

Ideally, I would like to keep the user out of the equation entirely, and store this secret some other way. Does Forge have any concept such as environment variables where something like an API token can be stored?

If I do go the UI / Forge secure storage route, do you all have any best practices on how I should prevent unauthorized users from tinkering with this “admin settings” part of the UI?

Any other options out there that I am not considering?

2

Welcome to the Atlassian developer community @BradleyFishman,

Can you explain a bit more about the distribution of your app? Mainly, is this app for your own org, or is it intended to be a Marketplace app distributed to many?

Yes, Forge does support environment variables.

For Jira, there is the jira:adminPage module that is only visible to admins. It’s meant for the configuration use case you described.

Since you also asked about other options, I want to make sure you know that Forge supports OAuth 2.0 for fetch with external APIs without having to build that yourself.

Along those lines, maybe you could say more about how this API token works, and whether you control both sides of the app? Depending on the architecture, Forge Remote might also be relevant.

1 Like
3

Thanks for the quick reply. Do you think the encrypted environment variable is secure enough to use in this case. Or is it not intended as such. Specifically concerned about this part “Encrypted values are protected from forge variables list output. However, they are passed to your app’s environment as clear text.”

This is not going to be distributed via the Marketplace (just for our org). And we are stuck with API keys (don’t have OAuth 2.0 as an option).

Can environment variable be set independently per deployment of the application? E.g., I have 3 sites I am deploying this on, can I have different env variables set for each.

4

@BradleyFishman,

Both encrypted storage and env variables are appropriate for secrets. I think plain-text variable injection is pretty standard and safe. When you obtain secrets from the encrypted storage, those are also going to be “passed to your app’s environment as clear text”.

Before I explain the options available, I want to be clear about the language in the Forge docs:

  • deploy (or deployment as a noun): The act of bundling and sending your app’s code to the Forge platform. App versions, environments, and env vars are coupled to deployment.
  • install (or installation as a noun): The act of authorizing and connecting your app to a specific site. The auth and storage are coupled to installation and are isolated between them. Site A cannot see Site B’s data or APIs (at least not without some Forge Remote acting as a proxy between them).

Apps must be deployed first before they can be installed on any site.

Yes. But, from your example, I think you meant env var per installation, which is no.

In theory, you could deploy the same app 3 times, and then install each one with separate env vars. That would mean you need to use forge register to get new app Ids, for each potential deployment, and juggle those ids for the same codebase.

In practice, this is too clever. It will make the already difficult relationship between your source code and the deployed versions more confusing. That, in turn, makes it confusing when you’ll have major versions and the necessary admin intervention to update. My team runs the Dev Assistant App, which we tried to manage as multiple deployments, and I don’t recommend it.

I recommend using 1 API key for the 1 API. Do use the env var option instead of the encrypted storage. Less configuration involving UI will be more secure; less chance to leak secrets. All 3 installations to your 3 different sites will share the same env vars and, hence, the same API key.

Refreshing on a cycle of days is a bit unexpected but simple enough with automation. Each time the secret changes, update the env vars (using the Forge CLI), and then redeploy. The change in variables won’t trigger a major version bump, which means updates happen automatically. And a simple continuous delivery pipeline should make it easy to redeploy on the rotation schedule.