Core system discovery

The addresses of core systems should be discoverable through the Arrowhead cloud and not by values in the configuration files. Well, all but the one being queried for the addresses that is.

At first I tried making application systems query the service registry (the simple solution). However, I realised that the service registry is now closed for everyone, but a few of the core systems. So unless we open it for requests on core systems, this is not an option.
The alternative road is to query the orchestration system - however, I presume that would require entries in the authorisation and orchestration database tables. Currently, it would be a big hassle to add these manually for all combinations of core systems and applications systems.

Unless anyone have a better suggestion, I'll leave this issue open. Hoping that the upcoming management interface or on-boarding procedure might open better roads...

There are two types of core systems: mandatory (SR, ORCH, AUTH), and supporting.

Regarding the mandatory ones, all app systems can have direct access to the SR and ORCH.

Auth is provided witihn orchestration all times. So, no direct contact with the AUTH is required when the given service does not support the token mode. It would be the best if we could force all services to support secure mode and above that, tokens.

However, when a given service is not supporting the token approach, it can have TLS secure connection to the AuthorizationControl service when it receives an inbound request, and can manually crosscheck the inbound client cert CN with the authorizationcontrol service.

Therefore, app sys-s need the address of the SR, AUTH and ORCH. This could be acquired if we use the autoconfig nature of the DNS-SD version of the SR, and can lookup there the HTTPS SR and HTTPS ORCH and HTTPS AUTH using DNS. But that is not very elegant, and the use of DNS is not favored apparently by partners (for corporate reasons), even though it has been the original technology behind the SR implemetation.

The second solution is that the bootstrapping process will give the app system these addresses.

The third solution is to give systems these details...

All app sys can have contact with the supporting core systems through the orchestration and all those service should support tokens as the most scalable security measure we have.

As I wrote in #28 the SR does not seem to be free for app systems (at least not for queries - register and remove is fine).

Neither does AUTH for the cert crosscheck you mention: AuthACF.java

If the SR queries should be free for all, an option could be to give app systems the IP for the SR only, then they can easily query the SR for AUTH and ORCH. Would provide a bit more flexibility, should someone decide to split the mandatory core system over several hosts in the future...

Sounds like a good idea to consider this along the bootstrapping process...

Yes, the HTTPS query interface for the SR is not open.

The AUTH should be, that might be a "feature". Will check.

Your idea is good, we have not fully thought about this part. We just used the config files so far.

Sorry, might have been too quick on the AUTH, apparently I can't read code today. Non-mgmt urls and mgmt/intracloud can be accessed if AuthForCloud is enable. If it is not they cannot:

if (AuthorizationMain.enableAuthForCloud) {
      if (!requestTarget.contains("mgmt") || (requestTarget.endsWith("intracloud") && method.equalsIgnoreCase("post"))) {
        String[] clientFields = clientCN.split("\\.", 2);
        return serverFields[1].equalsIgnoreCase(clientFields[1]);
      } else {
        return clientCN.equalsIgnoreCase("sysop." + serverFields[1]);
      }
    } else {
      if (requestTarget.contains("mgmt")) {
        return clientCN.equalsIgnoreCase("sysop." + serverFields[1]) ||
                (clientCN.equalsIgnoreCase("certificate_authority." + serverFields[1]) && requestTarget.endsWith("publickey") && method.equalsIgnoreCase("get"));
      } else {
        return clientCN.equalsIgnoreCase("orchestrator." + serverFields[1]) || clientCN.equalsIgnoreCase("gatekeeper." + serverFields[1]);
      }
    }

Seems to fit the description of AuthForCloud:

#Allow querying access to the authorization tables for application systems (true/false - only has effect in secure mode)
enable_auth_for_cloud=false

I assume there are differences between a DNS lookup and the HTTPS query interface that warrants the difference in permissions?

Yes, well, DNS is an insecure protocol. The DNS-SR version is basically an HTTPS bridge/frontend that relies on a BIND server. The DNS can only be secured using a pre-shared TSIG key, unsecuredly passed between the HTTPS bridge and the BIND. This can be somewhat secure, if it is done through localhost loopback.

So, in short, DNS can be used for a preliminary lookup of the HTTPS SR, ORCH and AUTH through the DNS protocol, but registration and removal can only happen using certs through the HTTPS bridge.

Sounds like this behaviour could be somewhat emulated by the SR-SQL. Thinking something like opening it for queries only for the SR, ORCH, and AUTH. Not sure that querying SR for SR makes sense, but at least the other two.

There would be a little security in the current state as it would require a signed certificate to perform the query - but again, such is trivial to obtain through the CA until on-boarding is in. A query need only to return the IP address though - not sure if this is so valuable to protect?

Depending on how far on-boarding is, it might also be a good idea to accept queries for CA until then. The issue here is that the app. system wouldn't have a signed certificate in this early stage, thus the SR have to (blindly) accept all.

Just brainstorming here: An entirely different route could be to register the SR, ORCH, and AUTH in DNS (even when using SR-SQL) and refer to them by domain names and not IPs. Installing a regular DNS server (not the exact BIND needed for full SR) should doable on most systems. A question is to what extend registering in it can happen automatically or if it has to be done manually. It could be integrated into the installation scripts for local DNS servers, but otherwise many would probably not use the feature if they have to do it manually. There'll no security on the core system IP addresses though. In this case we will also need an option for overriding the address of the DNS in the conf file, since not everyone may have the option of adding it to their default DNS server. Writing this mess makes me realise it's probably too complex to work with ease, I'll leave the idea here if you guys see anything in it.

In all cases the option of overriding IPs manually in the conf file could be kept as a work-around when it otherwise doesn't work...

I think having in the default corporate DNS server an entry to the Boostrapper module would be the best way. That module should have the accept-all interface, and give the address of the SR at the end oft he boostrapping.

In Arrowhead, we should aim at protecting even the IP addresses as much as possible. That is why I don't like the old approach, the DNS-SR. That is not secure one bit, when we want to use it as a shared DB. Once the write enabler TSIG key is out, then everyone can do anything with the DB. No control, whatsoever.

Right now, the CA is not an active module. I also think we should keep having to manually generate app sys certs for the moment. Not sure about the status of the onboarding.

progress on the certificate bootstrapping #2

Navigation Menu

Repository navigation

Core system discovery #2

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Core system discovery #2

Description

Activity

hegeduscs commented on Nov 6, 2018

eudyptula commented on Nov 6, 2018

hegeduscs commented on Nov 6, 2018

eudyptula commented on Nov 6, 2018

hegeduscs commented on Nov 6, 2018

eudyptula commented on Nov 7, 2018

hegeduscs commented on Nov 7, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions