Service account for API calls

Jira Development Jira Cloud
,
1

Hi,

I’ve been using API calls (in ScriptRunner) to create a test execution based on the tests in the test plan. No problem there. The API calls are successful. But these calls are all done with my personal account.

Is there a more general approach? I don’t want to use my own credentials.
And the company does not want to create a “fake” account for automation because the password will need to be reset every x amount of months.

Any suggestions are welcome.

Thanks in advance.

2

Hello @Frederik

Refer to this thread from last week, where essentially the same question was asked.

3

I had seen that thread. But they don’t want to create the specific user for automation.
So for me it’s not an option. My question is really if there is not a more general approach.

But I found a request for a service account here https://jira.atlassian.com/browse/JRACLOUD-69561

So I fear, at the moment it just doesn’t exist.

4

Hi @Frederik – You are correct that your ideal solution is not supported.

However, most organizations are able to design a workaround that satisfies their security requirements, etc. Without understanding the specifics of your situation, it’s difficult to recommend a good workaround for you. But I can at least share some common strategies:

  • Use a shared inbox to avoid creating a “fake user” in your internal user directory. Instead of creating a fake user account in your company’s internal user directory that requires having its own password, etc., use a shared email address to create the “service account” user in Atlassian Cloud. You can use an existing shared inbox, such as “[email protected]”, or you can create a dedicated shared inbox, such as “[email protected]”.
  • Use “plus-addressing” to create multiple service accounts from a single shared inbox. For example, if you need to create three service accounts for Atlassian Cloud, you can create three Atlassian “bot users” (i.e., “fake users”) with the following email addresses: “[email protected]”, “[email protected]”, and “[email protected]”. This only requires a single email address to be supported by your email server, but it will be seen as three unique users by Atlassian Cloud.
    Also, if you’re using an existing shared inbox such as your support email address, then you can create rules on your mail server to handle the bot notifications separately.
  • Use Atlassian Guard to create separate security policies for your bot users. I wouldn’t purchase Guard for only this purpose. But if you already have Guard, then you can use it to allow your “bot accounts” to follow different security policies than your “human” accounts.

Again, these are just common strategies. I don’t know what makes sense for your specific situation. But I believe you can probably design a solution that would at least be acceptable for your company.

Feel free to reply or direct message if you’d like some more ideas.

I hope this helps!

1 Like