-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create reusable JWT things #702
Create reusable JWT things #702
Comments
We need a way to take the public and private keys generated for JWT, and distribute them to all the places that depend on them: Drupal, Fcrepo, etc. This is pretty easy if everything is on one box, when its on multiple boxes its a bit harder to coordinate. Not sure what the best way to approach this one is. |
It's a real security task. Do we generate a one-use system of keys in order to distribute the keys that will be used in ordinary operation? And what does idempotency mean for this? |
I think maybe we should do something here that works for vagrant, basically generating a new set of keys everytime, but leave it fairly open to be overridden, since in a real production instance you would pre-generate the keys and add them to ansible vault or something like that. |
Okay, so the essential problem is how to distribute the keys? |
This is not exactly what we want, but it (seems) to be in the same ballpark. |
They are using Ansible Vault, looks like. |
I think if we want to automate the deployment of private keys to various remote servers, this would require someone with
|
Cool Found this ansible vault tut,
https://gist.github.com/tristanfisher/e5a306144a637dc739e7 and trying to
catch up. Are you planning on providing a simple unique one for dev purp?
Also a bit in the best practices doc
http://docs.ansible.com/ansible/latest/playbooks_best_practices.html#best-practices-for-variables-and-vaults
On the subway
El El mié, 23 de ago. de 2017 a las 16:17, A. Soroka <
notifications@github.com> escribió:
They are using Ansible Vault, looks like.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#702 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGn85xMs2M5avTxt_YtxtFRkGQKnPso-ks5sbIjdgaJpZM4O-y5K>
.
--
Diego Pino Navarro
Digital Repositories Developer
Metropolitan New York Library Council (METRO)
|
So this work requires the |
Ok also, we are creating the key in the |
But we could also need to provide the key instead of generating it. Assuming ansible will be used for actual production deployment. That's the reason for the ansible vault thing. If institutions want to have a "secret" key that they can still publish somewhere. Or that is how i understand it |
Ansible Vault seems (to me) like it is for storing normally plaintext files but with strong encryption. As private SSL keys (should) already have a password applied to them, I'm not sure if vault is the correct place. But I think the issue I have, is that each item is supposed to be its own role, but this task crosses those boundaries because either we are generating the JWT in place or we are copying it into the server and using it in Syn and Drupal. |
Are these actually SSH keys, or are they something different? |
They are keys for the JWTs, but not for SSH access. |
But they are SSH keys, in terms of their form and how they are generated? |
@whikloj so: let's say I want to provide my private key. How do I do it without the vault? |
Could we regen them as part of the task and still be idempotent in the right sense? http://docs.ansible.com/ansible/latest/list_of_crypto_modules.html |
They are technically PEM encoded RSA keys. IMO: We should do something that works for vagrant now where we would like to generate some keys, and slay the dragons of key distribution later when we start using this for other boxes. |
Well, as long as all roles are on the same node, couldn't we just put the keys somewhere all roles could see them? (I.e. not have separate copies for role) And also file a ticket to make that better. Somehow. |
@DiegoPino you have a good question. But (from my reading) to use ansible-vault you need to add an encrypted private key to the ansible-vault. But the key is already encrypted, so we are probably better figuring how to include it in the configuration. But I am still getting up to speed on this. |
@ajs6f I think that is definitely do-able, I was just trying to allow for separate instances server. ie. Tomcat separate from Drupal in my setup. But perhaps the key (😆 ) is to generate the keys first and then place them in one (or more) locations and reference them when generating the other (read: Drupal and Syn) configurations? |
@jonathangreen @whikloj also, i forgot this. Has Syn a bypass option for development purposes? |
@whikloj Totes agree that separable instances/roles is where we want to go. But I also agree with (what I think) @jonathangreen is saying, which is let's get our MVP (vagrant and sandbox use ansible) delivered. Then we breathe and rest up for the next set. |
@DiegoPino yes you can specify a static token to use |
What about the stuff in Karaf-- do we need to get keys to it so that it can go against stuff in Tomcat? |
Good point, where in Alpaca/API-X do we need that? |
@whikloj forget all my previous comments. I mixed a lot of stuff up. I need to remember never ever post while in a meeting |
It appears that the two options (I have found) are defining the variable at the top level or we could use "facts" to pass a variable from one role to another. Not sure which is better. I'll try defining the variable at the top for now. |
@whikloj Looks like you did a lot of research and work on this--where are we at? Do you still have it or do you want to throw the ball to me? |
@ajs6f I updated my code, but the ansible playbook likes to fail to build and (for all its idempotency) seems to be unable to recover. So I'm having to build the box several times to see if it worked. If you want to grab it and take it across the line, I'm fine with that. 👍 |
Ok, so I tested this and it seems to work except:
2 above means that if the system is on a single server, you'd end up with multiple copies of the key. But for separate servers you'll need to copy them anyways. |
@whikloj Can you be more specific about what doesn't work for Crayfish? I am going to punch this (I hope) as part of our current sprint... I did the Crayfish role, so it's my job to fix it. :) |
Crayfish also makes use of the "shared" key, but I did not have the various Crayfish services to look at the same spot for the key. But this is a bigger issue as we need to handle a multi-server setup and I think instead of (what I did here) of all pointing to a single key, we need instead to copy the key to the various locations. |
PR ready for test - Islandora-Devops/islandora-playbook#25 |
Re-opening. It autoclosed on us after merging Islandora-Devops/islandora-playbook#25 |
No description provided.
The text was updated successfully, but these errors were encountered: