Documentation for API HTTP Authentication / more simple auth process

1

Hello All,

I have recently began delegating development tasks to junior team members relating to the LXD API and the documented interface via swagger.

The documentation seems to be lacking on how to make a simple api request to an LXD cluster without going into rabbit holes on generate certificates.

The common complaint is that this whole process is over complicated and that there is no step by step guide on how to make a simple “List all instances” request to the api that doesn’t require first trying (and usually failing) to work out how to auth against the api.

Surely this is a barrier to entry for future developers else where?

Are there any efforts for a simple authentication mechanism that doesnt require a fair bit of manual work and understanding of the certificate creation process?

Perhaps i am being naive and have missed a really simple how to guide?

Please dont take this as discouragement, huge fan of the project and team.

Thanks

Matt

2

Have them develop against the socket which doesnt require auth?

Otherwise … build a dev version of LXD without the auth? I should imagine its a few lines in a front controller somewhere

3

Requests against the socket maybe a way forward but then requires giving developers access to the host so thats not really feasible.

Ideally looking for a missed piece of documentation or info on whether there is likely to be additional auth methods in the future?

Also with regards to custom building LXD, seems silly when were just trying to do a standard task against an api.

4

Certificate authentication is the easy method, the other methods we support or are adding now are more complex (signed macaroons or OIDC).

5 
stgraber@dakara:~$ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:4096 -keyout client.key -out client.crt
..+..+..........+...+...+..+...+...................+.....+....+..+...+.+........+..................+............+.+..+.......+..+....+.....+.+......+............+...+........+.......+.....+.......+........+...+............+...+......+...+..........+..+...+.......+.........+..+....+.....+....+.....+.+........+.+..+...+.......+..+...+...+.+......+.....+............+.+...........+...+......+.......+............+...+..+.+.....+..........+.....+.......+.....+...+.+.....+.+...+.........+..+.+.....+.......+..+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*.....+..+.+.....+...+.........+.+......+...+........+....+...+...........+.......+........+.......+..+.+..+...+....+........+.......+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*...............+..+.+......+...+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
......+......+.......+...+..+.........+...+......+.........+...+.........+.+............+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*.+..+...+.............+...+......+......+.....+....+...+..+.............+..+....+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++*.....+......+.............+........+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:.
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:.
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:foo
Email Address []:.
stgraber@dakara:~$ lxc config trust add client.crt
stgraber@dakara:~$ curl -k -s --cert client.crt --key client.key https://127.0.0.1:8443/1.0 | jq .metadata.auth
"trusted"
1 Like
6

Thanks for the response Stephane.

It sounds like that is a no :smiley:

I think this will be a barrier to entry as people attempting to integrate with LXD will be familiar with common cloud provider approaches where its very simple. Creating / exchanging certificates is an unwanted faff IMO.

7

Public cloud provider APIs usually use a mix of OIDC and OAUTH2 which I wouldn’t exactly describe as easier :wink:

In some cases, you can use bearer tokens but those are generally being phased out from many APIs as they are seen as problematic (no expiry/renewal process attached to them, making forced re-authentication during a compromise harder than it should be).

Now if you’re someone who finds OIDC and OAUTH2 easier, well, the good news is that LXD is getting those added. We have work in progress on OIDC and OAUTH2 will follow in the next 6 months or so.

8

Thank you Steph
my certificates are “trusted” but i can’t create container from remote IP (i’m using php-curl)

9 
curl -k -s --cert client.crt --key client.key https://127.0.0.1:8443/1.0/instances -X POST -d '{"name": "foo", "source": {"type": "none"}}' -H 'Content-Type: application/json'

That gets you a pointless (no rootfs) instance that you can’t start, but that works just fine here.

10

Note that when working with the API, it’s often easiest to use the LXD CLI with --debug so you can see exactly what the REST API request is that it’s making.

11

i success it the issue is from my image
curl -k -s --cert cert/cert.pem --key cert/cert.key -X POST -d ‘{“name”: “test”, “source”: {“type”: “image”, “alias”: “image-nginx”}, “profiles”: [“nginxprofile”]}’ -H “Content-Type: application/json” https://my_lxd_ip:8443/1.0/containers | jq .

12

Possibly. Maybe run lxc monitor --pretty on the side to see errors coming from LXD for background operations, at least until you have logic to handle background operations yourself.