Newbie: Agent Authentication

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Newbie: Agent Authentication

Raja
Hi,
Im trying to run a agent on separate node than the server and following the instructions (production mode). I was able to setup the zookeeper properly (only one instance) and when setting up the agent, create a pre_master_conf.sh and feed in the "required" properties as mentioned in http://pongasoft.github.io/glu/docs/latest/html/agent.html#configuration-properties

Now, I have not provided the agent's truststore or keystore password on the agent yet, but when I start the agent-server, there is a file in agent-server/data/config/agent.properties (seems generated) with all the passwords. So it seems that the Agent on booting up is calling the zookeeper to get all this information.

Is it normal to have this unauthenticated setup. Wouldnt it be possible for someone to register a node by just giving the zookeeper url and fabric name?

Thanks
Raja
Reply | Threaded
Open this post in threaded view
|

Re: Newbie: Agent Authentication

frenchyan
Administrator
The boot sequence section (http://pongasoft.github.io/glu/docs/latest/html/agent.html#agent-boot-sequence-and-configuration) explains what is happening: 

step 5: the file conf/agentConfig.properties is read and it contains by default the property used in step 6
step 6: during the tutorial setup (which you probably have followed), a config.properties has been stored in zookeeper and this file contains the keystores and passwords used during the tutorial.

Is it what you were asking or is your question more about the fact that you can essentially setup a glu agent with 2 parameters and you think this is not safe?

Yan
Reply | Threaded
Open this post in threaded view
|

Re: Newbie: Agent Authentication

Raja
frenchyan wrote
Is it what you were asking or is your question more about the fact that you
can essentially setup a glu agent with 2 parameters and you think this is
not safe?
Yeah, its about the fact that setting up an agent just involves configuring the Zookeeper url and the fabric name. That seems less secure as the server doesnt really authenticate the agent.  

Thanks
Raja
Reply | Threaded
Open this post in threaded view
|

Re: Newbie: Agent Authentication

frenchyan
Administrator
When you say "server" what are you referring to? What would you expect to happen?

Yan


On Sat, May 18, 2013 at 7:14 AM, Raja [via glu] <[hidden email]> wrote:
frenchyan wrote
Is it what you were asking or is your question more about the fact that you
can essentially setup a glu agent with 2 parameters and you think this is
not safe?
Yeah, its about the fact that setting up an agent just involves configuring the Zookeeper url and the fabric name. That seems less secure as the server doesnt really authenticate the agent.  

Thanks
Raja



If you reply to this email, your message will be added to the discussion below:
http://glu.977617.n3.nabble.com/Newbie-Agent-Authentication-tp4025726p4025728.html
To start a new topic under glu, email [hidden email]
To unsubscribe from glu, click here.
NAML

Reply | Threaded
Open this post in threaded view
|

Re: Newbie: Agent Authentication

Raja
Apologize if my terminologies are incorrect (been learning how glu works lately).

When I meant the server, I meant the node running the console-server. I suppose the console-server is the central node that all agents connect to and the one from which all the deployment activities are pushed out (Depending on what the deployment plan is).

So, with this assumption, any agent can still get registered with the console-server (using the Zookeeper url and the fabric name), but there could be some kind of an authorization process where you login to the Glu Console and indicate that those agents are infact valid agents. This would avoid someone who knows where the ZooKeeper runs to register themselves as valid agents (because there is still manual process to "approve" the agent).

Or is that what the keystores are supposed to do (help in authenticating the agent to the console server)?
I probably need to read through the section on generating the keys in the documentation.

Thanks
Raja
Reply | Threaded
Open this post in threaded view
|

Re: Newbie: Agent Authentication

frenchyan
Administrator
I see what you mean now. And yes I think the issue is that you have it backward :)

Agents never talk to the console, they are independent (and by the way you can use them independently using their rest api without ever using ZooKeeper or the console; it is definitely not the traditional setup, nor would you get the delta computation and orchestration, but it can be done for some specific needs...)

The agent registers itself in ZooKeeper and reports its state to ZooKeeper. The console uses ZooKeeper (through watchers/listeners) to figure out which agents are registered and in which state. When the console needs to "talk" to the agent, it does so using the agent rest api. This is what the page http://pongasoft.github.io/glu/docs/latest/html/index.html (tries to) explain.

What is important in terms of security is that when an agent is asked to do something (using its rest api), it needs to validate who it is coming from because of the fact that what the agent is about to do could be "dangerous". The agent on its own is not doing anything except listening for requests to do something, on its rest endpoint.

This is why (although you can disable it but it is NOT recommended), the agent listens on its rest endpoint using https with client authentication (http://pongasoft.github.io/glu/docs/latest/html/agent.html#security). The keystore(s) and truststore(s) that you need to setup is what provide the agent with the "public" key of the console so that when the console talks to the agent it can use its "private" key to encrypt/authenticate the originator of the communication.


Hope this makes sense
Yan

Reply | Threaded
Open this post in threaded view
|

Re: Newbie: Agent Authentication

Raja
Thanks Yan,  I have a much better picture now. Thanks for the detailed explanation.