Rego policies for Choria Server

Open Policy Agent is a CNCF incubating project that allow you to define Policy as code. It’s widely used in various projects like Istio, Kubernetes and more.

It allows you to express authorization policies - like our Action Policy - in a much more flexible way.

Building on the work that was done for aaasvc, I’ve added a rego engine to the choria server, which will allow us to do most of what actionpolicy allows, as well as:

  • Assertions based on the arguments sent to actions
  • Assertions based on other request fields like TTL and Collective
  • Assertions based on if the server is set to provisioning mode or not

Read below the fold for our initial foray into OPA policies and what might come next.

[Read More]

Choria Configuration

Choria configuration, despite efforts with Puppet module and so, is still very challenging. Just knowing what settings are available has been a problem.

We tried to hide much of the complexity behind Puppet models but for people who don’t conform to the norm it’s been a challenge.

I eventually want to move to a new configuration format - perhaps HCL? - but this is a massive undertaking both for me and users. For now we’ve made some effort to give insights to all the known configuration settings on the CLI and in our documentation.

First we’ll publish a generated configuration reference in CONFIGURATION.md - for now it’s in the Git repository we’ll move it to the doc site eventually.

As of the upcoming version of Choria Server you’ll be able to query the CLI for any setting using regular expressions. The list will show descriptions, data types, validation rules, default values, deprecation hints and URLs to additional information.

choria tool config

And get a list:

$ choria tool config puppet -l
plugin.choria.puppetca_host
plugin.choria.puppetca_port
plugin.choria.puppetdb_host
plugin.choria.puppetdb_port
plugin.choria.puppetserver_host
plugin.choria.puppetserver_port

These references are extracted from the Go code - something that I never imagine is possible - read on for details on how that is done.

[Read More]

Upcoming Server Provisioning Changes

I’ve previously blogged about a niche system that enables Mass Provisioning Choria Servers, it is quite scary and tend to be specific to large customers so it’s off by default and require customer specific builds to enable.

I’ve had some time with this system and it’s proven very reliable and flexible, I’ve had many 100s of thousands of nodes under management of this provisioner and can kick 10s of thousands of nodes into provisioning state and it will happily do thousands a minute.

The concept is sound and the next obvious step is to make it available to FOSS users in our FOSS builds. To get there is a long road one that I think will take us toward Kubernetes deployed Choria Broker, CA and Choria Provisioners and eventually a Puppet free deployment scenario.

It’s a long road and step one is about looking at how we can safely enable provisioning in the open source builds. Read on for the details of what was enabled in Choria Server 0.13.0 that was released on 12th of December.

[Read More]

Open Policy Agent in AAA Service

Open Policy Agent is a CNCF incubating project that allow you to define Policy as code. It’s widely used in various projects like Istio, Kubernetes and more.

It allows you to express authorization policies - like our Action Policy - in a much more flexible way.

I’ve wanted to explore what is next for our general Authorization piece and I think this gets us to a very good place - and OPA have massive adoption so it’s always good to adopt widely used standards.

Using Open Policy we’ll be able to do a number of things we’ve never been able to do - but get asked about regularly:

  • Make sure requests have filters associated to avoid huge blast radius
  • Assertions based on the arguments sent to actions
  • Assertions based on other request fields like TTL and Collective

And just generally be much more expressive about it.

Read below the fold for our initial foray into OPA policies and what might come next.

[Read More]

December 2019 Releases

It’s been a while since we had release announcements and it’s been a surprisingly busy period.

The main focus here has been on a number of stability and bug fixes, we’ve had some users dig in really deep into various aspects of the system and a number of bugs were squashed.

Past the quality of life stuff I have started reworking Choria Server Provisioning which will set us on a path to having a good Puppet free story, I have some POCs lying around of a Kubernetes based Broker, CA, and Provisioner that will give a really smooth path forward - provisioning is now compiled in to the FOSS stack by default and can be enabled using a JWT token, more on that in a future post.

We also include a Tech Preview of NATS JetStream support and significantly moved our event formats over to Cloud Events v1.0 format.

Thanks especially go to Alexander Hermes for his deep dive into all aspects of the client side playbooks. Deep dives into a product and filing some tickets, discussing the model on slack etc it hugely time consuming and very often this kind of community contribution flies under the radar but I find it more valuable than code, huge props to Alexander.

Other shout outs to Ben Robert, Yury Bushmelev, Romain Tartière and Vincent Janelle

[Read More]

New JetStream Adapter

The upcoming Choria Server release will support publishing fleet data to JetStream a new Streaming Server from the folks who built NATS - the core technology of the Choria Broker.

This technology is currently in tech preview and so we’ve added early support for it so Choria users can test it for their needs.

Support for JetStream will be in the nightly build tonight and a release will be soon.

Read on for some background on the why and how.

[Read More]

Transitioning Events to CloudEvents

When we first introduced our Lifecycle Events we mentioned efforts by cloudevents.io to standardize a format and set of transports but that it was a bit early in their life to adopt it.

Cloud Events is now a CNCF Incubator project and they reached CloudEvents 1.0 which means there is now a standard to work around that is stable. A good introduction to the concept can be found in The CloudEvents Spec Seeks to Bring Uniformity to Event Data Descriptions.

Since then adoption of this format has exploded - a whole bunch of companies and projects support ingesting and routing CloudEvents, examples: solo.io with their event powered API gateway, OpenFaaS, Serverless.com Event Gateway, Oracle Cloud, Azure, Knative and many many more.

So for us the time is ripe to adjust the format of our events to support CloudEvents 1.0. As of the next release of the Choria Server the Life Cycle events and Autonomous Agent Events are all been transitioned to CloudEvents format.

[Read More]

External Python Agents

The latest release of Choria includes support for external agents, so now writing agents in any language is possible. For those of us who prefer to use Python to manage our systems, we have a new library, py-mco-agent which is intended to make it as simple as possible to write Choria agents. The simplest possible agent can be written with just a few lines of code.

[Read More]

September 2019 Bug Fix

Today I have a small few bug fixes to ship, these will affect only people who are experimenting or using our newly announced External Agents support, others can safely ignore this.

Thanks to Ben Roberts for his assistance with these releases

[Read More]

September 2019 Releases

Today we are doing a series of long overdue Puppet Module releases as well as a reasonably significant Choria Server update.

Significantly this delivers the new External Agents I blogged about recently.

Read on for all the details!

[Read More]