Gateways

Summary

Gateways are special relays that operate a local storage hub to make it available to other Cosnim instances. They are useful for creating a private cloud storage service based on local or enterprise storage without going to the cloud. Gateways can also serve as firewalls to further shield local or cloud storage against attacks.

Configuration

Gateways are defined in the ‘gateways’ section of the configuration. They are almost identical to relays, except that they also include the definition of a storage hub. The gateway server will operate the storage hub locally and make it accessible to other client instances. The security protocols are the same as relays. See the Configuration Reference for the exact parameters required to configure a gateway server and client configuration. Here is an example of a gateway configuration:

gateways:
  my-gateway:
    client:
      url: tcp://115.19.236.161:24101
    server:
      url: tcp://0.0.0.0:24101
      provider:
        type: file
        path: /data/my-gateway-storage/capsules
        autocreate: True

To use a gateway, client instances need to define a capsule hub configuration with a provider of type: gateway. For example, to use a gateway as a private cloud provider in a staging hub named ‘control’:

hubs:
  control:
    max_capsule_size: 256 KiB
    max_elements: 2000
    type: staging
    keep_cached: yes
    max_memory_size: 512 MiB
    stages:
    - provider:
        name: control-stage-1
        type: file
        path: /my/local/path
        autocreate: True
        relay: primary
    - provider:
        name: control-gateway
        type: gateway
        gateway: my-gateway
        namespace: my-namespace

Where ‘gateway: my-gateway’ identifies the name of the gateway to use.

Namespaces

Gateways have an additional naming convention item called ‘namespace’. A namespace is an additional layer added to the path of capsules to distinguish capsules between users and instances that are going through the same gateway. This allows different users and continuums to share common storage without interfering with one another. See the Configuration Reference for more information about how namespaces interact with other naming elements such as prefixes.

Immutability Firewall

Gateways can be transformed into full-fledged immutable storage firewalls simply by setting the ‘immutable’ option to True in the configuration. When this option is activated, gateways will accept only requests that operate capsule storage as true WORM (Write Once Read Many) storage. This protects all capsules stored in the gateway against destructive and corruption attacks from client instances, which improves resiliency to cyber and ransomware attacks.

You can leverage gateways to transform any storage, not just local storage, as fully immutable storage. For example, if a given cloud provider does not provide sufficient security policy options to fully shield storage, or you desire a higher level of security, you can use gateways to add this protection to that storage.

Atomic Storage Gateway

Gateways can also be used to provide atomic update capabilities to providers that don’t have this ability.

Atomic storage is required in special applications, such as when hubs store control capsules in shared filesystems. To transform a non-atomic storage provider into a fully atomic storage, use a gateway between the client instances and the cloud.

Security Firewall

Gateways can also protect access to cloud storage by acting as an intermediary between client instances and the cloud storage. This can be used to hide the cloud storage provider’s credentials or to enhance security further. You can use gateways to front-end any type of capsule hub and provider.

How to deploy

Except for the additional provider parameters that define which storage is going to be handled by a gate, gateways are deployed exactly as a relay (See the Relays section for details).