matt-kubica / iot-tunnel Goto Github PK

Thanks to vavr, most of the logical flow is acomplished using Try. There is need to configure some sort of middleware that would convert tries returned in controllers to http codes.

In order to to provide well-built exception handling mechanism all code parts that deal with exception should be using vavr.

Configuration service would be a service on a server's end, that would periodically upload os configuration to registered gateways. Updates would be conducted using ansible and ansible playbooks.

Right now client's config can be generated in a pretty automated manner - there is job container that generates client's config on compose startup. The downside of this approach is non-scalablity - config is generated only once, only for one client. There is need for service which:

• will be running constantly and be ready to generate client's config
• will keep information about generated configs / certificates
• will talk to CA in order to generate client certs / keys
• will keep track of generated configs - the unique id of client / config will be device's main interface physical address
  • it won't override config for id that already exist in database
  • it will allow deallocating config - revoke certificate

It's worth to examine ways of revoking certificates with cfssl and its API, also it's worth to checkout OpenVPN management interface.

There are two types of integration tests to consider:

• management-service integration tests - those would examine how components of this service cooperate, i.e. full flow from request to interactions with database and (maybe?) other services
• system integration tests - some sort of automated procedures that would examine how different services interacts with each other, most importantly, how creating/deleting gateways work.

Let's consider creating dummy client-service docker image that would be open vpn client. Container of such image would:

• request creation of new gateway on startup
• obtain configuration
• configure itself as vpn client
• test connection with server
• shutdown after some time
  Such service would not be placed in same docker network as open vpn server. Besides, on server's end there could be dummy test-service (which already exist but hasn't has any logic to it) which would monitor ccd and would try to ping client listed there.

The challanging part here - agregating results from distributed set of containers (clients) and preparing summary. Possibly, there are some tools whose allow that - to be investigated.

Right now IpAssigner is basically dummy service with minimal required functionalities. It should be able to:

• assign ip addres choosen by some algorithm to provided common name
• assign provided ip address to provided common name
• revoke ip address
• (?) change ip address for certain common name

Especially the algorithm of choosing new ip address should be designed, also there should be possibility to define CIDR of allocation pool's subnet. Most likely it would be helpful to create wrapper class for ip addresses.

In order to maximize security in a system, OpenVPN clients shouldn't be able to access any services on a server's end besides OpenVPN server itself. To be more precise, they shouldn't be able to initialize connections, because both clients and certain services on a server's end should be able to communicate with each other, but only certian services on a server's end should be able to initialize connections.

Right now, there is additional route pushed to all new client's at initial configuration:

• 172.16.0.0/16 via 10.8.0.1
  On a server's end, currently only one service is able to access clients - test-service and this is possible because there is route created on a service startup:
• 10.8.0.0/16 via $OVPN_ADDR, where latter is ip address of OpenVPN server from a 172.16.0.0 subnet
  This is fine, not all services need to be able to access clients and if there will be such necessity it could be configured.

To summarize, there is couple of things to do:

1. there is need to configure firewall in a central point - OpenVPN Server - so it will reject new connections from 10.8.0.0/16 to 172.16.0.0/16,
2. additionally, it would be nice to stop using static ip addresses. Server's end network as well as OpenVPN pool should be configurable in a way that all those routes, firewall rules etc. will be resolved dynamically and addresses will be configured in only one file.

Unit and integration tests should be implemented, proposed framework: groovy-spock

Generally management-service is a adhesive that joins all the other services together. Because of that, despite of managing it's own state it can also alter other service's state. For example, registering new gateway entity comes with some sort of external side effects:

• /etc/common/ccd directory is altered by creation of new file - config that holds ip address of particular gateway
• certificate store is altered when new client's certificate with pk is created
  Those two exemplary actions are executed in a chain - whenever chain of procedures fail, procedures that are forth in a chain won't be executed, but the procedures that have already been executed might had polluted some external state.

In a tiny environment it shouldn't be a problem, but generally it's something that shouldn't happen - procedures need to form transactional chain, so external state will be modified only when all procedures have executed successfully, if any of them fail, everything should be rolled back to the state that occured before attempt to execute transactional chain.

Since this issue is far well complicated that one can think, maybe other ways of cleaning global state should be iplemented, for example - periodical job that would clean orphaned pieces of state, i.e. certificate not associated to any entity etc. It would be probably less elegant solution, but also easier to implement.

Stack overflow thread can be found here, by the time this issue is created there are no answers or comments at all, what might imply that problem of transactions is not trivial at all.

Since OpenVPN server will be runned in the cloud, it is necessary to came up with a sollution that would allow configuring instance/container with code. OpenVPN client will be runned on a embedded device (most probabbly RaspberryPi), sot it is necessary to configure it with code as well - the minimal user interaction should be required, perfectly - no interaction.

For now shell scripts should be sufficeint.

Right now, there is no validation of custom application properties, however, service startup should fail if there are malformed props. For example:

• IpAssigner's internal pool
• paths to shared volumes

It is necessary to implement very basic monitoring-service that would run on a server's end and would periodically:

• retreive list of registered gateways
• make request with ModbusTCP
• display retrived value
  Of course, this would be very limited functionality, normaly there should be some sort of dynamic configuration/registration of modbus slaves and their corresponding registers. The goal of this implementation would be to make dummy requests in order to proof that there is connectivity.

On the gateways' end there would be 'modbus-bridge` service. Such service should be containerized and configurable so it could run in two modes:

• actual bridge mode - in this case modbus requests/responses would be forwarded back and forth between monitoring services and slaves with conjunction of TCP and RTU flavours of protocol
• dummy mode - in this case, service on a gateway's end would just produce random values

Since modbus-bridge would be containerized service, it should be built externally and then pulled to particular gateway at the time of initial configuration (using ansible).

Some of the providers present in management-service don't require to obtain new data every time it's requested. To save some processing time and bandwidth it would be worthy to introduce some sort of caching, maybe with caffine.

When there are multiple concurrent requests to management-service that are ment to assign ip using SharedVolumeIpAssigner, non unique addresses may be assigned because this service is not thread safe.

It should be fixed in a way that IpAssigner's public methods would be thread safe or underlying logic would be thread safe in particular places. First option is probably easier, but the second one wcould be more optimized.

To investigate:

• how to revoke certificate using cfssl api
• what kinds of params are necessary

As stated here, it looks like right now, management-service doesn't keep track of necessary variables.

Right now all Dockerfiles used in a project are based on a latest ubuntu image. Although it is comfortable as those images are more user friendly, in a future it is necessary to make them use LTS alpine images.

Right now, service makes use of JPA which significanly reduced development time. Unfortunately JPA doesn't work well with vavr - it allows to use Option<T> as return type of get methods, but there is no support for vavr iterables, moreover it doesn't allow to use streams so lazy loading cannot be utilised.

Currently, in order to persist compability with vavr some not really elegant hacks need to be used so either full support for vavr needs to be configured or custom repository compatible with vavr needs to be implemented.