Discussion of geard roadmap about geard HOT 15 CLOSED

Auth-keys is used to generate an authorized keys file suitable for use with the AuthorizedKeysCommand in ssh - basically, you can dynamically generate the the public keys that should be allowed to log in for an account when someone tries to login, vs up front. This means that you don't have to regenerate auth keys files when keys change, only when someone tries to login. Also, it generates the authorized_keys file with a specific wrapper command that handles figuring out how to get the user into the container - via switchns - and in the future would also allow things like different access levels for Git because the command can generate environment variables that get passed to that command script.

add-keys sends a public key to the server and associates it with a specific container or repository. When SSH is properly configured (which it isn't by default, we have a todo to add that doc) - an ssh attempt by a system user associated with a container (geard creates users for each container) will look into the keys associated with the container - finding a match, it would allow login to proceed, run switchns to put the user into the container in /bin/bash.

init-repo generates a git repo inside of a single container - the "geard-githost". This container has a git environment and is an equivalent to something like gitorius. The init repo command does a switchns into the container on behalf of the unix user associated with the git repo (so that someone can ssh in), then invokes a known script to generate a git repo. In this case the user is more like a normal system user - the container runs with elevated privileges, but inside the container the user is constrained by SELinux and regular unix permissions, so they can access their own repo dir but not much else.

All of the complexity here is bridging the gap to future work in Docker that would allow remote execution of commands over SPDY from a local client (docker exec with remote invocation), but also to continue to support existing SSH / Git patterns that are difficult to reimplement, like Kerberos based SSH or secure Git hosting. It's using traditional unix patterns, just in moderately complex ways.

from geard.

Ok. That answer definitely helped me connect the final bits. Checking the list of command I think the only one I'm missing if create-token. I think it's for signing some request made to a remote gear daemon. But I'm not sure if this happens by default on the back, or if it's for some additional encryption? Most simply, don't see where this is used practically. Any help is appreciated! Thanks.

from geard.

It's not used quite yet by the client - the idea would be that for requests with delegated trust (Alice has the private key, signs a request to give to Bob who can then use that with Claire). It just works for content requests today - which is just the environment file info. However you can pass a URL for an env file to install container (via the API), and the agent would load it:

• Alice wants to install container 1 on Bob's machine and use an existing environment from Claire's machine.
• Alice signs a token request to fetch Claire's environment file, makes it into a URL that points to Claire's geard agent, then sends that URL as part of an install container request to Bob
• Bob sees the URL and blindly fetches it (because he trusts Alice), Claire gets an incoming token request and allows it (because it's signed by Alice), and Bob now has a copy of the contents on his machine

The delegated trust allows other scenarios eventually, like I can generate a URL that lets you fetch an archive of your Docker volumes from a server for a limited time (and with request id tracking, even only once if a want to). Or I can generate a URL for a client that lets them fetch logs from a container in their browser from me. Basically gives us one way to disintermediate a central orchestrator from having to proxy all of the large, slow data from a cluster member to arbitrary clients.

from geard.

More info about trust relationships in a cluster are described here: https://github.com/openshift/geard/blob/master/docs/orchestrating_geard.md

from geard.

I see. But then this isn't used just yet, it's like a structure added there at the moment but pending real usage in the current state of the project? I assume ttrust relationship topic is related to the options in the contrib folder where it says this:

https://github.com/openshift/geard/blob/master/contrib/geard.defaults

# Specify the directory containing the server private key and trusted client public keys
#GEARD_OPTS="${GEARD_OPTS} --key-path=''"

So, there's no use in setting those keys? Basically, there's no security layer at the moment to interact with the daemon if exposed to the net? Like the way docker was before 0.10?

from geard.

Correct - TLS is high on the list but were hoping to get the transport abstraction in shortly so we don't complicate message broker transports. Will be soon though.

from geard.

Sounds great. Is there a short post on the intended roadmap? Who's working on the project, why? I have been keeping an eye for weeks, I took notes to understand the code as it's today and just want to learn where it's heading, why it exists on the first place, etc. We are trying it out in a small cluster of about 5 machines to deploy stuff using geard+serf events.

from geard.

Matt does a great job of laying out the "why" here: https://www.openshift.com/blogs/geard-the-intersection-of-paas-docker-and-project-atomic

I've got a todo to draw out a roadmap and will have something soon.

from geard.

Quite fresh. Thanks for the link. To keep up to date should I join the openshift mailing list or not much on that side? Also, how is versioning being made at the moment, I see I can get this on Fedora 20, probably better that my own compiled version that I was sending through Ansible playbooks to our machines; however don't know how distinguish what version I'm running/installing.

from geard.

OpenShift mailing list would be a good place to ask questions - that's where any public discussion and threads are going to be ([email protected]). Versioning is still 0.0.x - we don't embed it in the build but we should start doing that soon so that gear --version shows something relevant.

from geard.

Understood, thanks for solving all my questions.

from geard.

I've added a comment to the read me about our public trello board https://trello.com/b/KfPwHUAy/openshift-geard - still working through a roadmap blog post that covers where we want it to go.

from geard.

Great. Lots of activity happening lately in the repo with a lot of improvements. Looked at the Trello cards and from a totally practical perspective was very interested in "R&D Prototype a design for getting hooks into Git repos during create / afterwards via geard". Right now I was using an alternative image with our own repo structure as a temporary replace githost.

from geard.

@davidpelaez yeah, that's something @ncdc was looking at - both up front addition, and the ability to add/update/delete later. Not sure how flexible that should be right now.

from geard.

Probably not worth having this opened keeping space in the issues list. Closing it since many of my questions have already been solved.

from geard.