How to inject private SSL certificates to kas-container

[Jörg Sommer]

Hi,

I have to fetch the source for a Yocto recipe from a self-signed webserver. How can I add the certificate to the trusted certificate store in the container started by kas-container?

Kind regards

Jörg Sommer

Software Developer / Programmierer

-- 

Navimatix GmbH Tatzendpromenade 2 07745 Jena	T: 03641 - 327 99 0 F: 03641 - 526 306 M: joerg....@navimatix.de www.navimatix.de
Geschäftsführer: Steffen Späthe, Jan Rommeley Registergericht: Amtsgericht Jena, HRB 501480 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

[Jan Kiszka]

On 17.11.23 11:50, 'Jörg Sommer' via kas-devel wrote:
> Hi,
>
> I have to fetch the source for a Yocto recipe from a self-signed
> webserver. How can I add the certificate to the trusted certificate
> store in the container started by kas-container?
>

This specific use case has not been addressed yet, but it is
conceptually close to ssh. We could add a switch to bind-mount the
host's cert folder into the container. Not sure if that folder is
standardized over all distros, though. If not, we would have to make the
path an argument.

Jan

--
Siemens AG, Technology
Linux Expert Center

[Jörg Sommer]

Would it be possible to add an option `--pre-code …` to supply any shell
code that gets executed by *container-entrypoint* before `exec kas`?
This would make it possible to change anything in */etc/ssl*, e.g.
remove unwanted certificates.


Kind regards

Jörg Sommer

--
Navimatix GmbH
Tatzendpromenade 2

D-07745 Jena

[MOESSBAUER, Felix]

On Mon, 2023-11-20 at 11:07 +0100, 'Jörg Sommer' via kas-devel wrote:
> On 17.11.23 13:13, Jan Kiszka wrote:
> > On 17.11.23 11:50, 'Jörg Sommer' via kas-devel wrote:
> > > Hi,
> > >
> > > I have to fetch the source for a Yocto recipe from a self-signed
> > > webserver. How can I add the certificate to the trusted
> > > certificate
> > > store in the container started by kas-container?
> > >
> >
> > This specific use case has not been addressed yet, but it is
> > conceptually close to ssh. We could add a switch to bind-mount the
> > host's cert folder into the container. Not sure if that folder is
> > standardized over all distros, though. If not, we would have to
> > make the
> > path an argument.
>
> Would it be possible to add an option `--pre-code …` to supply any
> shell
> code that gets executed by *container-entrypoint* before `exec kas`?

Hi Jörg,

for me, this interface looks a bit too generic. If needed, it is always
possible to create derived custom containers to make all kinds of
modifications.

In general, the kas-container should be a slim wrapper around KAS to
run the build in an well-defined, stable and isolated environment. By
that, it is also discouraged to wrap the kas-container script in
another script. With support for the pre-code option, I already see
people adding a ton of commands there to modify the build environment,
which makes the builds less portable. The request for some proprietary
tools like the GCS binaries recently requested goes into a similar
direction.

> This would make it possible to change anything in */etc/ssl*, e.g.
> remove unwanted certificates.

If you only want to make changes to the certs (e.g. to provide a fixed
set of certs), simply mount a folder from the host at /etc/ssl, using
the container runtime args. If this use-case becomes a pattern, we can
provide a switch to bind-mount the hosts cert folder, as proposed by
Jan.

Best regards,
Felix

[Jörg Sommer]

On 20.11.23 14:31, MOESSBAUER, Felix wrote:
> On Mon, 2023-11-20 at 11:07 +0100, 'Jörg Sommer' via kas-devel wrote:
>> On 17.11.23 13:13, Jan Kiszka wrote:
>>> On 17.11.23 11:50, 'Jörg Sommer' via kas-devel wrote:
>>>> Hi,
>>>>
>>>> I have to fetch the source for a Yocto recipe from a self-signed
>>>> webserver. How can I add the certificate to the trusted
>>>> certificate
>>>> store in the container started by kas-container?
>>>>
>>>
>>> This specific use case has not been addressed yet, but it is
>>> conceptually close to ssh. We could add a switch to bind-mount the
>>> host's cert folder into the container. Not sure if that folder is
>>> standardized over all distros, though. If not, we would have to
>>> make the
>>> path an argument.
>>
>> Would it be possible to add an option `--pre-code …` to supply any
>> shell
>> code that gets executed by *container-entrypoint* before `exec kas`?
>
> Hi Jörg,
>
> for me, this interface looks a bit too generic.

It's not so uncommon to have hook in some stages where you can inject code.

> In general, the kas-container should be a slim wrapper around KAS to
> run the build in an well-defined, stable and isolated environment. By
> that, it is also discouraged to wrap the kas-container script in
> another script.

Unfortunately, kas-container is not very alias friendly to make the
usage convenient. The most disturbing is the config file parameter *at
the end* that is used sometimes and sometime not (menu). And sometimes
other parameters follow this config file parameter, and sometime not.

An option -c would make it possible to have aliases like

alias kc_dev='./kas-container -c dev-settings.yaml'

I've also extended my wrapper with some tools to work with the container
from outside; like find-ipk, console-log, list-logs, cd-src, runqemu.
Good tools offer some mechanism for extension, think of git aliases.

> With support for the pre-code option, I already see
> people adding a ton of commands there to modify the build environment,
> which makes the builds less portable.

But isn't it up to the user to care about what he does? A knife can be
used in good and in bad ways. But it's not the responsibility of the
cutler, what happens with the knife.