a9s CF Service Guard

This section describes the operation of the a9s CF Service Guard component.

The a9s CF Service Guard is intended to ensure that a proper Cloud Foundry (CF) App Security Group (ASG) exists for each and every Service Instance, so that a CF app can reach out to the provisioned Service Instance from its CF space.

Overview

The a9s CF Service Guard relies on a9s Consul and the a9s Service Brokers, that are part of each service deployment, to manage the ASGs in CF.

It uses a feature from Consul called Watches to be informed as soon as there is a change in the list of network nodes, e.g. a new Service Instance is created. The received catalog of nodes is then filtered by a configured list to ensure that only nodes from Service Instances are considered in the next steps. For each remaining node, the configured a9s Service Brokers are called to ensure that this node belongs to a Service Instance provisioned with the a9s Data Service Framework (DSF). If the node belongs to a Service Instance known by an a9s Service Broker, a corresponding ASG is created in CF, an existing one is updated or even deleted when the Service Instance has been deleted.

Additionally, the a9s CF Service Guard can check if a Service Instance is shared into another space in CF and create an extra ASG so that this Service Instance is also reachable from this space.

Cloud Foundry App Security Groups (CF ASGs)

The CF ASGs are named after the GUID of the corresponding Service Instance and prefixed, by default, with a9s-asg-. To list the existing CF ASGs, run:

$ cf security-groups

This will return a response similar to:

Getting security groups as admin
OK

     Name                                           Organization   Space
#0   services
#1   public_networks
#2   dns
#3   a9s-asg-34f22bce-d540-46c0-9efd-8bf293ad0a95   anynines       test
#4   a9s-asg-933c47ba-e3fc-4b00-9549-6fd8f323f3ca   anynines       test

Background Workers

The a9s CF Service Guard distributes the work to different background workers that are described in the following.

consul_nodes_processor

The consul_nodes_processor is responsible for processing the incoming catalog of Consul Nodes. It filters the catalog by the configured allowed_consul_nodes list and compares it with the nodes that are already in the database to detect if there are new nodes or stale nodes. If one of the two applies, then the corresponding database entry is marked as unsynchronized to be processed by the security_groups_synchronizer.

security_groups_synchronizer

The security_groups_synchronizer is responsible for managing the ASGs in CF. It checks regularly if there are unsynchronized database entries and if there is one, it will either create, update or delete an ASG in CF depending on the state of the corresponding Service Instance.

shared_spaces_updater

The task of the shared_spaces_updater is to manage the required ASGs for Service Instances that have been shared in CF. To do so, it checks periodically for each Service Instance, that is known by the a9s CF Service Guard, if it has been shared to other spaces. Then it compares this with the internal state in the database to see if there are new shared spaces or less and binds or unbinds the related ASGs from the found spaces.

TLS Configuration

The a9s CF Service Guard comes with TLS (HTTPS) enabled for its API by default.

note

The a9s CF Service Guard is only configurable to listen to HTTPS and does not support HTTP anymore.

Additional Documentation

• a9s Consul
• Consul: Watches
• Cloud Foundry: App security groups
• Cloud Foundry: Sharing Service Instances

Limitations

a9s Search vs a9s LogMe2 Service Instances

a9s Search and a9s LogMe2 are using the same underlying data service, a9s OpenSearch, and the structure of the deployment templates is similar. This results in Consul Node names that look alike and cannot be differentiated by the a9s CF Service Guard. Although it is not necessary to have CF ASGs for a9s LogMe2 Service Instances and the related a9s Service Broker is also not configurable, the configured a9s Service Brokers are checked and this leads to additional requests and error messages in the logs.

note

This behavior can be prevented by using individual deployment name prefixes for the different a9s Data Services in combination with an appropriate regular expression for the allowed_consul_nodes property.