Hi everyone,
Is it possible to handle git authentication in a test job ? I need LAVA to clone a repo that can't be set to public, and obviously it won't work because of the authentication step. So is it possible to specify a password or a token ?
Best regards, Axel
On Tue, 20 Nov 2018 at 10:42, Axel Lebourhis axel.lebourhis@linaro.org wrote:
Hi everyone,
Is it possible to handle git authentication in a test job ? I need LAVA to clone a repo that can't be set to public, and obviously it won't work because of the authentication step. So is it possible to specify a password or a token ?
You can use 'secrets' section in the job definition. Docs here: https://master.lavasoftware.org/static/docs/v2/publishing-artifacts.html?hig...
It might be also a good idea to limit access to the job to user or group so the password doesn't leak. It has to be plain text unfortunately.
milosz
Ok good to know. Do you have a job definition example including secrets ?
On Tue, 20 Nov 2018 at 11:46, Milosz Wasilewski < milosz.wasilewski@linaro.org> wrote:
On Tue, 20 Nov 2018 at 10:42, Axel Lebourhis axel.lebourhis@linaro.org wrote:
Hi everyone,
Is it possible to handle git authentication in a test job ? I need LAVA to clone a repo that can't be set to public, and obviously it won't work because of the authentication step. So is it possible to specify a password or a token ?
You can use 'secrets' section in the job definition. Docs here:
https://master.lavasoftware.org/static/docs/v2/publishing-artifacts.html?hig...
It might be also a good idea to limit access to the job to user or group so the password doesn't leak. It has to be plain text unfortunately.
milosz
On Tue, 20 Nov 2018 at 11:03, Axel Lebourhis axel.lebourhis@linaro.org wrote:
Ok good to know. Do you have a job definition example including secrets ?
There are quite a few but you need to be a member of the groups who have the rights to access the secrets to see those test jobs.
On Tue, 20 Nov 2018 at 11:46, Milosz Wasilewski milosz.wasilewski@linaro.org wrote:
On Tue, 20 Nov 2018 at 10:42, Axel Lebourhis axel.lebourhis@linaro.org wrote:
Hi everyone,
Is it possible to handle git authentication in a test job ? I need LAVA to clone a repo that can't be set to public, and obviously it won't work because of the authentication step. So is it possible to specify a password or a token ?
You can use 'secrets' section in the job definition. Docs here: https://master.lavasoftware.org/static/docs/v2/publishing-artifacts.html?hig...
It might be also a good idea to limit access to the job to user or group so the password doesn't leak. It has to be plain text unfortunately.
milosz
Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
On Tue, 20 Nov 2018 at 11:03, Axel Lebourhis axel.lebourhis@linaro.org wrote:
Ok good to know. Do you have a job definition example including secrets ?
these are top level entries. Example below:
visibility: group: - my_secret_group
secrets: TOKEN: 123456789abcd
milosz
OK thank you for this example. In my job definition I have something like this : - test namespace... . . . definitions: - repository: https://<link to private git repo> from: git ....... How do I use the token in this case ?
On Tue, 20 Nov 2018 at 12:31, Milosz Wasilewski < milosz.wasilewski@linaro.org> wrote:
On Tue, 20 Nov 2018 at 11:03, Axel Lebourhis axel.lebourhis@linaro.org wrote:
Ok good to know. Do you have a job definition example including secrets ?
these are top level entries. Example below:
visibility: group: - my_secret_group
secrets: TOKEN: 123456789abcd
milosz
On Tue, 20 Nov 2018 at 13:07, Axel Lebourhis axel.lebourhis@linaro.org wrote:
OK thank you for this example. In my job definition I have something like this :
- test namespace... . . . definitions: - repository: https://<link to private git repo> from: git .......
How do I use the token in this case ?
Huh, I didn't think about this use case and I don't think it's supported (didn't find anything in the docs). To work around that you might need to do the inline test that performs 'git clone' on the target.
milosz
On Tue, 20 Nov 2018 at 13:07, Axel Lebourhis axel.lebourhis@linaro.org wrote:
OK thank you for this example. In my job definition I have something like this :
Tokens are available in the test shell, as per the documentation, as a parameter.
If you call your secret TOKEN in the test job definition then TOKEN will be available in the script called by the test shell action.
- test namespace... . . . definitions: - repository: https://<link to private git repo> from: git .......
How do I use the token in this case ?
You can't. You would need to embed the TOKEN in the URL which defeats the object.
Add a previous test shell definition which accesses the TOKEN and then does the git clone as a command in a script from a public git repository.
Alternatively, change the network topology to allow the worker to access the private git repo without needing any tokens. e.g. in some labs, each worker is whitelisted so that any access from that IP is deemed to already be authorised for selected private URLs.
On Tue, 20 Nov 2018 at 12:31, Milosz Wasilewski milosz.wasilewski@linaro.org wrote:
On Tue, 20 Nov 2018 at 11:03, Axel Lebourhis axel.lebourhis@linaro.org wrote:
Ok good to know. Do you have a job definition example including secrets ?
these are top level entries. Example below:
visibility: group: - my_secret_group
secrets: TOKEN: 123456789abcd
milosz
Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
On Tue, Nov 20, 2018 at 01:39:55PM +0000, Neil Williams wrote:
On Tue, 20 Nov 2018 at 13:07, Axel Lebourhis axel.lebourhis@linaro.org wrote:
OK thank you for this example. In my job definition I have something like this :
Tokens are available in the test shell, as per the documentation, as a parameter.
If you call your secret TOKEN in the test job definition then TOKEN will be available in the script called by the test shell action.
- test namespace... . . . definitions: - repository: https://<link to private git repo> from: git .......
How do I use the token in this case ?
You can't. You would need to embed the TOKEN in the URL which defeats the object.
Add a previous test shell definition which accesses the TOKEN and then does the git clone as a command in a script from a public git repository.
Alternatively, change the network topology to allow the worker to access the private git repo without needing any tokens. e.g. in some labs, each worker is whitelisted so that any access from that IP is deemed to already be authorised for selected private URLs.
Or if you can't control that (e.g. remote public git server like github), embed ssh keys into your test images, or have the image grab those keys from a restricted location on your network.
There are quite a few possibilities - it depends on how complicated your needs are, and how ingenious you can be. :-)
Cheers,
On Tue, Nov 20, 2018 at 02:30:53PM +0000, Steve McIntyre wrote:
On Tue, Nov 20, 2018 at 01:39:55PM +0000, Neil Williams wrote:
Or if you can't control that (e.g. remote public git server like github), embed ssh keys into your test images, or have the image grab those keys from a restricted location on your network.
There are quite a few possibilities - it depends on how complicated your needs are, and how ingenious you can be. :-)
Actually, as Neil just pointed out - I've misundestood what you were asking. Ignore me... :-)
Cheers,
Thanks everyone for your answers. I will try to find a work around.
Regards, Axel
On Tue, 20 Nov 2018 at 15:37, Steve McIntyre steve.mcintyre@linaro.org wrote:
On Tue, Nov 20, 2018 at 02:30:53PM +0000, Steve McIntyre wrote:
On Tue, Nov 20, 2018 at 01:39:55PM +0000, Neil Williams wrote:
Or if you can't control that (e.g. remote public git server like github), embed ssh keys into your test images, or have the image grab those keys from a restricted location on your network.
There are quite a few possibilities - it depends on how complicated your needs are, and how ingenious you can be. :-)
Actually, as Neil just pointed out - I've misundestood what you were asking. Ignore me... :-)
Cheers,
Steve McIntyre steve.mcintyre@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs
Hello Alex,
if you are admin of the dispatcher, then you can use git-credentials-store (see https://git-scm.com/docs/git-credential-store) as root. In fact, lava-run (the process actually booting the board, deploying the overlay, ...) is ran as root. So if root does have access to your git credentials then lava-run would also have access.
Keep in mind that if you use git-credentials-store on the dispatcher, any jobs running on this dispatcher will have access to your credentials! So this solution is only acceptable for private dispatchers.
Rgds
Le mar. 20 nov. 2018 à 17:17, Axel Lebourhis axel.lebourhis@linaro.org a écrit :
Thanks everyone for your answers. I will try to find a work around.
Regards, Axel
On Tue, 20 Nov 2018 at 15:37, Steve McIntyre steve.mcintyre@linaro.org wrote:
On Tue, Nov 20, 2018 at 02:30:53PM +0000, Steve McIntyre wrote:
On Tue, Nov 20, 2018 at 01:39:55PM +0000, Neil Williams wrote:
Or if you can't control that (e.g. remote public git server like github), embed ssh keys into your test images, or have the image grab those keys from a restricted location on your network.
There are quite a few possibilities - it depends on how complicated your needs are, and how ingenious you can be. :-)
Actually, as Neil just pointed out - I've misundestood what you were asking. Ignore me... :-)
Cheers,
Steve McIntyre steve.mcintyre@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs
Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
Hi Rémi,
Thank you for this tip. I didn't know about this possibility. Atm, I found a way to use a public repo but I will check this :)
Regards, Axel
Le jeu. 13 déc. 2018 à 13:43, Remi Duraffort remi.duraffort@linaro.org a écrit :
Hello Alex,
if you are admin of the dispatcher, then you can use git-credentials-store (see https://git-scm.com/docs/git-credential-store) as root. In fact, lava-run (the process actually booting the board, deploying the overlay, ...) is ran as root. So if root does have access to your git credentials then lava-run would also have access.
Keep in mind that if you use git-credentials-store on the dispatcher, any jobs running on this dispatcher will have access to your credentials! So this solution is only acceptable for private dispatchers.
Rgds
Le mar. 20 nov. 2018 à 17:17, Axel Lebourhis axel.lebourhis@linaro.org a écrit :
Thanks everyone for your answers. I will try to find a work around.
Regards, Axel
On Tue, 20 Nov 2018 at 15:37, Steve McIntyre steve.mcintyre@linaro.org wrote:
On Tue, Nov 20, 2018 at 02:30:53PM +0000, Steve McIntyre wrote:
On Tue, Nov 20, 2018 at 01:39:55PM +0000, Neil Williams wrote:
Or if you can't control that (e.g. remote public git server like github), embed ssh keys into your test images, or have the image grab those keys from a restricted location on your network.
There are quite a few possibilities - it depends on how complicated your needs are, and how ingenious you can be. :-)
Actually, as Neil just pointed out - I've misundestood what you were asking. Ignore me... :-)
Cheers,
Steve McIntyre steve.mcintyre@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs
Lava-users mailing list Lava-users@lists.lavasoftware.org https://lists.lavasoftware.org/mailman/listinfo/lava-users
-- Rémi Duraffort LAVA Team
lava-users@lists.lavasoftware.org
-
Axel Lebourhis -
Milosz Wasilewski -
Neil Williams -
Remi Duraffort -
Steve McIntyre