Skip to content
TinyBloxTinyBloxTinyBlox

Connections between products

Products call each other: TinyConductor reads secrets from TinyVault, the connector runtime fetches jobs from TinyConductor and secrets from TinyVault, TinyConductor asks the connector runtime to test a stored connection. Every such connection is configured the same way in every product.

Status: TinyConductor 0.2.0 coming is the first release with these settings, for its connections to TinyVault and to the connector runtime, and for its script worker. The other products adopt them in their next releases.

The settings

Section titled “The settings”

A connection setting is the calling product’s own prefix, then the target, then a key:

<CALLER PREFIX>_<TARGET>_<KEY>


CONDUCTOR_TINYVAULT_URL                        TinyConductor, to TinyVault
CONDUCTOR_TINYCONDUCTOR_CONNECTORS_URL         TinyConductor, to the connector runtime
CONDUCTOR_SCRIPT_WORKER_TINYCONDUCTOR_URL      the script worker, to TinyConductor
Target Section Default transport Port
TinyVault TINYVAULT mesh 8080 (TLS: 8443)
TinyGuard TINYGUARD plain 8080 (TLS: 8443)
TinyConductor TINYCONDUCTOR plain 8080 (TLS: 8443)
The connector runtime TINYCONDUCTOR_CONNECTORS plain 9090

The same keys follow for every target:

Key Meaning
URL The target’s address, http://host:port or https://host:port. Worked out by the chart; see below.
TRANSPORT How the connection is protected: mesh, plain or tls.
CA_FILE Extra trusted certificate authorities, for a tls target with a private certificate.
TIMEOUT The longest one call may take, for example 10s.
TENANT A fixed tenant at the target, when it differs from the caller’s own.
AUTH_MODE How the caller signs in: oauth (a machine client, the default) or a mode the target offers.
AUTH_TOKEN_URL, AUTH_CLIENT_ID, AUTH_CLIENT_SECRET The machine client at the identity provider.
AUTH_AUDIENCE, AUTH_SCOPES What the token is asked for.

Secrets also accept a _FILE form, for example CONDUCTOR_TINYVAULT_AUTH_CLIENT_SECRET_FILE.

You rarely set these yourself: the charts set them from a few values.

How the address is worked out

Section titled “How the address is worked out”

Inside one Kubernetes cluster, every product’s Service has a predictable name, so the caller’s chart builds the address itself:

<service>.<namespace>.svc.<cluster domain>


service     the target's release name when it contains the chart name
            (release "tinyvault"), otherwise <release>-<chart>
namespace   the target's namespace (default: the caller's own)

So with nothing set, TinyConductor installed next to TinyVault reaches it at http://tinyvault.tinyblox.svc.cluster.local:8080. Each chart has one values block per target, with the same keys:

clusterDomain: cluster.local
connections:
  tinyvault:
    release: tinyvault             # the target's Helm release name
    namespace: ""                  # empty: this release's namespace
    url: ""                        # set: used as it is, nothing is worked out
    transport: ""                  # empty: the target's default
    ca:
      configMap: ""                # tls only: the CA's public certificate
      key: ca.crt
    timeout: ""
    auth:
      mode: oauth
      existingSecret: ""           # empty: <release>-oidc-tinyvault

To set the same values once for every TinyBlox chart of an environment, use global.tinyblox.clusterDomain and global.tinyblox.<target>.*; a chart’s own values win.

How a connection is protected

Section titled “How a connection is protected”
Transport Address What protects it Use it when
mesh http://…:8080 your service mesh’s mutual TLS the cluster runs Istio, Linkerd or another mesh. TinyVault’s default.
plain http://…:8080 nothing but the network around it the connection stays inside one cluster, NetworkPolicies let only the caller reach the target, and the cluster runs no untrusted workloads
tls https://…:8443 the target’s own TLS, with a certificate from your environment’s private certificate authority there is no mesh and the connection must be encrypted
  • Plain is never a guess. An http address with no transport set is refused. A plain connection logs a warning at start, and the metric …_connection_transport_verified shows 0 for it, so your dashboards show every unprotected connection.
  • TinyVault refuses plain unless you accept it explicitly in its chart, because its answers are secret values.
  • With tls, certificate checks cannot be switched off.

One certificate authority for the environment

Section titled “One certificate authority for the environment”

A cluster address such as tinyvault.tinyblox.svc.cluster.local cannot get a certificate from a public authority, so an environment that uses tls has one private certificate authority for all its products, for example a cert-manager CA issuer called tinyblox-ca.

  • Give the callers only the CA’s public certificate, as a ConfigMap tinyblox-ca with the key ca.crt, and point connections.<target>.ca at it.
  • Never give a caller a Secret that also holds a private key.

Credentials: machine clients

Section titled “Credentials: machine clients”

A product signs in to another with a machine client at the identity provider. Its Secret is named after the caller and the target:

Caller, target Secret
TinyConductor, TinyVault tinyconductor-oidc-tinyvault
connector runtime, TinyConductor tinyconductor-connectors-oidc-tinyconductor
connector runtime, TinyVault tinyconductor-connectors-oidc-tinyvault

The Secret holds client-id, client-secret, token-url and audience. The provisioner writes it; without it, create it yourself with the same keys. TinyConductor does not sign in to the connector runtime as itself: it passes on the token of the person who asked for the test.