Otter Feature Request - Set up a 'collector' of sorts to use in a multi tenant datacenter

Jonathan.Engstrom

Hello, I have a question for a possible feature request. I am trying to avoid having different installation instances of Otter in separate domains. I would like to run the same code for each servers, but each tenant has their own set of "unique" (/sarcasm) requirements that are prohibiting communications to the existing Otter server. Would it be possible to create a minimal "collection" node that runs as a relayin other environments (AD domains/ forests) to run jobs, collections, executions and reports the data back to the Otter Server? Does this make sense?

Product: Otter
Version: 2.1.3

g.j.spoelstra_9664

This is an interesting feature request; from Otter's early design, we wanted to support environments with complex communication restrictions.

Our idea was to accomplish through an agent relay of sorts. Basically

                                         --->  [Inedo Agent A]
[Otter] ---> [Inedo Agent Relay Service] --->  [Inedo Agent B]
                                         --->  [Inedo Agent C]

For example, you would configure a server in Otter like:

Server Name: server123
Host Name: server123.client.corp
Relay: bridge-server.local

In this case, bridge-server.local can talk to server123.client.corp, where as the Otter server cannot. However, if the Relay Service was installed on the bridge-server, then Otter could still orchestrate server123.

Is that what you were referring to?

Jonathan.Engstrom

Yes, that is somewhat what I was thinking, except for I am not using agents; I am wanting to do this with PowerShell (WinRM).

I have Otter installed in/on one domain, and would like to run a "relay service" on a set of servers that already has access to multiple tenants, and relay the communication from the Otter Server, to the Relay, to the client. Data from Client will start from the client, travel to the relay, then be communicated to the Otter server.

Keep in mind my problem is related to firewall issues and politics, hence the use of WinRM and not agents, thanks!

Jonathan.Engstrom

So are there any other thoughts with this? Does this sound doable at all? Thanks!

atripp

I spoke with the engineering team briefly on the issue, and here's some quick feedback.

If we support "double-hop" authentication in the Inedo Agent, we would implement that functionality ourselves, using our own secure channels to ensure end-to-end security. Fortunately that's relatively easy to do, since we control both ends of the pipe.

This is not the case in PowerShell, and we cannot bypass PowerShell's security measures. PowerShell Remoting (and Kerberos) already has the concept of "double hob" authentication. It's very complicated, so we'd encourage you to read this article to understand the challenges with it.

So, long story short, if we implement a relay service ("double-hop authentication") in the Inedo agent, we may be able to use the same UI to control PowerShell, but there is a significant amount of configuration and control required to get it to work.

As far as the concept of "collectors", we will be researching a major new feature to Otter that simplifies the collection of like you're describing. So we'll consider it in there

Jonathan.Engstrom

Hello Alana, thanks for the update. I understand the double hop issue with credssp and the challenges using Kerberos. I was thinking of a remote machine that sends it's data to a collector, or a mini Otter server of sorts. This mini server would then send the collected data to the master (mega? :) ) server witch adds the results to it's own. So the client would never attempt to communicate with the master server, only the collector/mini server thus bypassing any double hop complexity. Almost the same principal of a secondary server if you are familiar with Microsoft SMS/ System Center Configuration Manager. Does this make sense?

atripp

I'm not familiar with SCCM so well, but I think I understand. Let me try to reexplain though just to make sure.

Otter should be able to routinely "publish" server configuration (i.e. the key/value pairs) that it collected to another instance of Otter
Otter should be able to "listen" for server configuration that is sent from another instance of Otter, and then apply (overwrite) that configuration to any matching servers

Am I understanding correctly?

Jonathan.Engstrom

Yes, something like that. The master/main server additionally would be set to listen to collector servers. The collector/mini/secondary server would communicate with the host servers like Otter normally does. The exception is that because the clients are unaware of the master/main server, they only send the data to the collector. The collector then sends the data back to the master server. Really, the only difference is adding the ability to one Otter Server to send server configuration data upstream so one can see all of the otter farm (Otter pond? :) )

atripp

Got it! Then this would likely fall inline with an upcoming major feature, and the communication between Otter servers ("main" and "secondary" as you describe) would be done using API/HTTPS/Web requests, in a direction of ("Publisher" -> "Listener").