Access shared credentials from shell script task

[Maksym Grebenets]

How can I access Shared Credentials from Bamboo plan Shell Script Taks?

I have added a private RSA key in Shared Credentials. I know I can use it to configure access to repositories or even in SCP plugin task.

But how can I access this key in a shell script task?
Is there a way to do that, e.g. via global variable?

In my case I have to do various things via SSH, like port tunneling, rsync via SSH and so on.
So I have to run scripts like

ssh -i id_rsa_private_key SOME COMMAND HERE

And I want to be able to pick up this id_rsa_private_key from Shared Credentials via plan or global variable.

[Marcin Gardias · Accepted solution]

At the moment Shared Credentials only work for checking out git repositories.

[Jesse Sanford]

Atlassian this is a terrible security practice. How in the hell has this product gotten this far without someone saying... HEY WE PROBABLY SHOULDN'T REQUIRE PEOPLE TO STORE PRIVATE KEY MATERIAL ON EVERY SINGLE BUILD AGENT!?!

[Jenna Salau]

All these comments are from 2014... its now 2019! It seems this is still not possible :(

[Vinh Hong]

Why the hell they call this "Shared credentials" when it isn't shared

[Jim Schwarz]

Having started in Jenkins and ported to Bamboo for a customer I wondered why they preferred Bamboo to Jenkins.  Lots of talk about open source and "security".  Having developed the same app now in both, Bamboo looks far less secure than the free Jenkins due to this very issue.  Handling secure credentials in Jenkins is very easy to set up and use in any shell or sql query, but do the same in Bamboo is impossible, and the only solution is so insecure it's crazy.  Oh, but you mask variables with "password" in the name, that's not secure at all.

[Maik]

2020 and still there's no way to use shared credentials across plans? :( In jenkins this is super easy to do. I wonder why there's no support for this feature yet

[Jesper Jakobsen]

I define Global variables  and access with ${bamboo.SOME_NAME}.

Only bamboo admin can access global variables and the scripts are clear of secrets, if you name them something with password they will not be visible from log outputs.

[rickmellor]

We install private keys used for this purpose on our instances via Bamboo instance configuration. In the instance startup script we add a method to dump the key to a file on the instance. This is then used during the build flow. It would be better to have access to the shared credentials in Bamboo ... maybe in the future they'll add this?? :)

[JRob]

+1

[onemb]

... maybe in the future they'll add this?? :)

Hello @rickmellor @2014,

here's a message from the future for you:

" x-D No."

[rsperafico]

Hi Maksym,

Unfortunately, Bamboo does not have a variable to get Shared Credentials set up on your Bamboo. Instead, what you can do is create system variables which can be used in all fields of a Task, with the exception of password variables. Variables can also be used with deployments.

At this point you might have a variable called JAVA_HOME set up in your environment variables. If you want to access it in Bamboo, you can use the following command:

${system.JAVA_HOME}

Based on the example above, you could set up a variable to hold your SSH KEY or the command you have described in your comment description and call it in within Bamboo.

Kind regards,
Rafael

[Maksym Grebenets]

Hi Rafael.

Yes, I could just plant the key on Bamboo system and then access it via environment variable. The problem is that we have around 10 Bamboo agents, all of them being a cloud instance. Those are managed by a separate team, and are refreshed every 2 weeks or so, that means the keys would be removed too and I would have to go through it with dev support guys to see if it's even possible to have a persistent key on all agents. Probably it's possible, but I was looking for a "Bamboo-way" only, as if I have no knowledge at all which agent will pick up the build, what's the agents OS and so on.

I tried to set the key as a plan variable, but the key is too long and exceeds maximul length.

So I ended up storing the key in the repositories of the projects that use it.
Not the ideal solution, but we're hosting Stash ourselves, the access to it is completely secure, that means the key is secured as well.