What is the best / working way to provide a resticted remote image server?
I already read the docs like Security but I’m missing a way to not only have just public images for the world but also images for a restricted (known) list of lxd servers/customers to allow commercial software to be installed the legal way.
Using lxd as an image server one has only the public option not to give full control to the own server which is of course not intended 
Would it be possible to setup a HTTP-Server described as “a static web server” in LXD 2.0: Image management 5/12 with authentication lxd is able to handle?
So I indeed wouldn’t recommend using the LXD protocol for that.
You should be able to run either a server serving simplestreams formatted images or just using plain images with the right HTTP headers as described in the Importing from a URL part of post you linked to.
For restricting access, you’ll want to setup your server so that it uses HTTP basic auth, either offering a completely different view per-user or just restricting access to the actual image files.
On the client you can then use a URL like: https://username:password@my-website.com/path
Thanks - the url encoded username/password is indeed a work around. We will go that way.
Since the tarball image url can’t be used directly for the import we need to code something anyway and could also go for a “security by obscurity” approach using somehow cryptical urls like shared docs in nextcloud/dropbox.
Maybe someone already implemented something like that?
An enhancement for lxc import would be some sort of authentication which is not part of the url like client cert auth or POST parmameters which are not part or the URL.
Does the Importing from a URL aproach also support listing like lxc image list ubuntu:?
Nope, lxc image import https://... does not support listing.
Listing is only possible with remotes and the only supported remote types are LXD or simplestreams.
I’m using simplesreams configuration for our private image server. We have just applied simple firewall restrictions which IMHO is always better than count on password protection.
Hello @stgraber,
like Heiko, I’m trying to set up a self-hosted, private image server that serves a subset of images depending on the requesting user. Some kind of authentication is required to distinguish individual users and serve them a list of images to which they’ve been granted (reading) access.
For context, the image server is intended to be used by a smaller user base (in contrast to users in a large-scale company). If possible the served images should be consumable by the LXD client directly.
I’ve researched different approaches to conceptualize such an image server, though all approaches have some kind of drawback or missing features to fulfill the aforementiond requirements.
As noted here and here, the LXD protocol supports TLS certificates to authenticate users, though access control to images on a per-user basis is missing.
[I’m sorry for having to split my post but new users can only post 5 links in a single post.]
A more promising option seems to be LXD protocol + candid + RBAC. While candid is open-source, RBAC requires Canonical RBAC service that is only available with a paid Ubuntu Advantage subscription as stated here.
In the same discussion you mention that …
LXD internally does not check for the protocol but instead behaves entirely based on the capabilities as detected on connection, so for example one could have a remote LXD server added with RBAC authentication which would appear as if it’s a full remote LXD but have the RBAC permissions restrict it to be a read-only image server, acting in much the same way simplestreams does. An admin could then change that permission and have it now act like a VM-only server within seconds.
This sounds great. But is it correct that this approach requires a paid Ubuntu Advantage subscription for RBAC as well?
@simos stated that there are no free RBAC service implementations available (as far as he knows). There might be a free plan for Canonical RBAC covering a limited number of machines using https://landscape.canonical.com. However, the image server and associated RBAC service should be self-hostable without depending on a third party.
Might RBAC be overdo since it offers control of a much wider variety of capabilities that aren’t used/required?
The proposed solution for Heiko uses the simplestream protocol that is meant to be for public image servers and as such having no private images:
Simplestreams: The Simplestreams protocol is a read-only, image-only protocol used by both the LXD client and daemon to get image information and import images from some public image servers (like the Ubuntu images).
In combination with HTTP basic auth users can be authenticated and different views be served depending on a user and its access permissions to images.
Nonetheless, you pointed out yourself that user credentials are likely to be logged.
Ah yeah, basic http authentication does work, though LXD is completely unaware of it and your login/password will be passed directly to any LXD server you use the remote with, the LXD server is similarly unaware of it being credentials so will happily log them and potentially put them in user visible location. Proper auth support would be either certificate based or supporting some kind of token which does not get logged all over the place
Regarding “potentially put them in user visible location”: since the credentials are part of the remote url, they would also appear in the output of lxc remote list, right?
Both aspects pose a security risk that should be avoided.
In conclusion, I agree that a custom simplestream server might be the easiest approach. But any authentication method other than HTTP basic auth is not natively supported by the LXD client.
Perhaps my research resulted in misconceptions or there are other approaches that I have not considered yet. In any case I would be grateful for any ideas and suggestions.