As i have got now official “go” from my boss i want to announce our VyOS 1.3 HTTP-based deployment backend.
The tool has currently no name - internal name is “routingwebapp”. It provides an REST API for several semantic parts of VyOS configs, especially Firewalls and Ruleset generation, Basic Network Interface configuration. It works by diffing a running config and a generated one and pushes commands against the 1.3 HTTP API. Technically it is based on a combination of Django(restframework), Celery and a message broker like RabbitMQ.
- The good: This backend will be open source, we are currently evaluating which OSI approved licenses do match best.
- The bad: I have to remove references to our internal infrastructure before i can open the source, this will take a bit time, don’t ask for ETA (as always in these contexts).
- The ugly: It’s alpha, no warranty, it’s likely there will be some breaking changes in the API. There is currently nearly no documentation and that’s horrible.
technical detail
Current list of entities, so you get an idea what our thoughts were while designing:
- general
- Router (+VyOS13Router): a router
- StaticConfigSection (+VyOS13StaticConfigSection): a static configuration part of config for things that can’t be generated
- Deployment: for tracking deployments via API
- user management
- Customer: a tenant or customer. Can be child of another → multi-tenancy-plus!
- User: a user is always part of a customer (django’s user is not flexible enough to implement it)
- LocalUserAuth: an authentication method for user, currently the only one
- network management
- Network: an IP Network
- ManagedInterface (+ManagedVRRPInterface): an interface description
- firewall management
- Firewall: the firewall (consisting of rulesets)
- RuleSet: a reusable set of rules
- Rule: (abstract) definition of a rule
- StandardRule: a simple rule just defining src, dst and dst service, should be enough for 90% of firewall rules
- CustomRule: a complex rule, more like StaticConfigurationSection but in rule context rather than global context
- AddressObject: (abstract) describing adresses
- ServiceObject: (abstract) describing services
- NetworkAddressObject: (-> AddressObject) links to an existing Network
- CIDRAddressObject: (-> AddressObject) CIDR (in both protocols)
- HostAddressObject: (-> AddressObject) a single IP (in both protocols)
- ListAddressObject: (-> AddressObject) a list of other AddressObjects
- SimpleServiceObject: (-> ServiceObject) a single port
- RangeServiceObject: (-> ServiceObject) a portrange
- ListServiceObject: (-> ServiceObject) a list of other ServiceObjects
- change management (in preparation), think a bit like a non blocking session
- ChangeSet: A set of changes
- Change: A change on a single entity
Current state:
- deploying firewalls using the semantical entities using the state in the database is possible
- the API is working for CRUD of above items, currently without Sessions
- triggering a deployment is currently only working in some cases (that’s where the change management comes in)
- it’s quite monolithic
- security is nearly not implemented (we will need it, but it’s simply currently nearly not implemented)
I’m working in a iterated way on this, so things are likely to change.
why i’m doing this?
Simply because my company needs it. The company does hosting in a B2B context usually providing also networks to customers for more flexibility.
I’m a bit sorry for doing redundant work to @robertoberto. There was a long time no reaction, so i had to start our own thing because managing our routers in current way is not scalable. Our work does not intend to make his work obsolete, it’s simply a different context and more GUI centric and without API:
Maybe in future we can combine things. As we need especially the central configuration management and want to integrate it in our existing web portal, it’s unlikely we will provide a generic GUI for this backend.
I’ll release the link to the code in this topic, as soon it’s ready.
