Be able to provide the image pulling credentials per run

[yifan-gu]

Currently when pulling the images from a registry, rkt will read authentication config files under /etc/rkt/auth.d. However this prevents multiple users saving their credentials at the same time. Besides this is not safe as different users are able to see each other's credentials

We need a way to provide the credentials via cmd line flags so that each rkt run/fetch takes its own credentials, (e.g. via --auth=file/json) and also by this, the credentials can become invisible to others.

[alban]

Would Kubernetes use this? How would this relate to --local-config= and --system-config=?

Could we use the standard XDG directory $XDG_CONFIG_HOME for user config instead?

[jonboulle]

I was also thinking about the XDG approach, it would be good to go that route as long as we're consistent with it (e.g. is our local/system config setup congruent with theirs?)

[alban]

The XDG spec uses the default /etc/xdg/rkt ($XDG_CONFIG_DIRS) and ~/.config/rkt ($XDG_CONFIG_HOME) by default. Moving /etc/rkt to /etc/xdg/rkt is annoying, that would be an incompatible change... rkt could maybe use $XDG_CONFIG_HOME but not $XDG_CONFIG_DIRS.

Otherwise, the XDG spec lets implementations free to define rules for merging between local config (/etc/xdg/rkt) and user config (~/.config/rkt) as we want. It does not specify anything about system config (/usr/lib/rkt), so we would be free to define our local/system config as well.

About the option --auth=file/json: is it useful to give a single file rather than a directory? When starting a pod containing several apps, the user might need to give a credential for each app.

[iaguis]

Moving /etc/rkt to /etc/xdg/rkt is annoying, that would be an incompatible change...

What about?

/etc/rkt -> /etc/xdg/rkt

[jonboulle]

rkt could maybe use $XDG_CONFIG_HOME but not $XDG_CONFIG_DIRS.

That's annoying, but I guess systemd.units is setting that precedent :/

[krnowak]

I see no sense in following XDG Base Directory Specification as long as rkt is a basically root-only application (and rkt group helps in nothing useful). I suppose we can start thinking about user configuration when we get the possibility to create containers as normal users. An example: if a non-root user is not in rkt group then they must fetch images with sudo and by using sudo they lose the XDG_CONFIG_HOME environment variable unless they will explicitly forward it.

A run-time parameter might alleviate some of the problems above, provided that the user is aware that the image they downloaded with their credentials is available now for use to anyone on the machine. So, what we could do is to provide a general --user-config which points to the directory with the same structure as the local or global configuration directories. User config directory would be to local config directory like local config directory is currently to system config directory - whatever specified in user config directory has precedence over the rest.

I'm opting for a general --user-config flag instead of a specific --user-auth-config flag just to keep it simple and to have fewer flags (we would have to add a new flag for each new directory in config).

[jonboulle]

+1 to krnowak's assessment, basically :-)

On Tue, Nov 3, 2015 at 5:43 AM Krzesimir Nowak notifications@github.com
wrote:

I see no sense in following XDG Base Directory Specification as long as
rkt is a basically root-only application (and rkt group helps in nothing
useful). I suppose we can start thinking about user configuration when we
get the possibility to create containers as normal users. An example: if a
non-root user is not in rkt group then they must fetch images with sudo
and by using sudo they lose the XDG_CONFIG_HOME environment variable unless
they will explicitly forward it.

A run-time parameter might alleviate some of the problems above, provided
that the user is aware that the image they downloaded with their
credentials is available now for use to anyone on the machine. So, what we
could do is to provide a general --user-config which points to the
directory with the same structure as the local or global configuration
directories. User config directory would be to local config directory like
local config directory is currently to system config directory - whatever
specified in user config directory has precedence over the rest.

I'm opting for a general --user-config flag instead of a specific
--user-auth-config flag just to keep it simple and to have fewer flags
(we would have to add a new flag for each new directory in config).

—
Reply to this email directly or view it on GitHub
#1568 (comment).