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?
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.
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.