Coming in the first release. This page describes behaviour being built for the first Gliss release. Details may change before it ships.
The stack builds the cluster and installs the Gliss agent. The agent connects out to Gliss over port 443; your cluster needs no inbound access from Gliss. When it finishes, a conformance check reports on the install.
After the install
- The catalog. The cluster uses the catalog you chose when you registered it, the default catalog unless you edited it.
- Apps find the cluster by themselves. When your organisation has one cluster, every new app is assigned to it, and apps registered before the cluster are assigned when it is registered. With several clusters, an organisation admin chooses one on the app’s page. If an admin removes an app from its cluster, Gliss never assigns it again on its own.
Release keys
Gliss signs every release with one key per Gliss environment. The verified launch script from the Gliss console prints the fingerprint of the key it checks the release with (Release key SHA-256 fingerprint: …) before it uses anything. Compare it with the one below for your environment. If they differ, don’t run the rest: stop and contact Gliss.
The line the script prints comes from the same console as the script, so check the key yourself before you run it. Copy the value of
release_key='…' near the top of the script and run printf %s '<that value>' | base64 -d | sha256sum. The result must be the fingerprint above. (From a key file: openssl pkey -pubin -in <key file> -outform DER | sha256sum.)
Every field, with its rules and CloudFormation parameter: Install parameters. The full requirements and permission list will be published here.