Sites

Wrap the sealkey shares with a key held in an external key store. At boot the site asks the key store to unwrap them and unseals without operator interaction. A key-store failure is an error, never a silent downgrade to TPM or plaintext protection.

Free form name of the site.

• edge
• top

Map of string keys and values that can be used to organize and categorize (scope and select) sites.

In addition to the configured labels, the following labels are added by the system to the operational state, which means that they are available for matching.

• system/name: contains the value of the site's name
• system/type: contains the value of the site's type

A label name consists of an optional prefix followed by /, followed by a name segment. The optional prefix is a DNS host name (must match inet:domain-name). The name segment must match ava:name.

The prefix system is used for labels assigned by the system.

Label names without prefixes are reserved for application owners.

For example:

• system/controller
• example.com/location.city
• example.com/color
• color

When a site is quarantined no replication of secrets will be replicated. The site will not be allowed to authenticate towards its parent, and cannot auto-unseal.

Block upgrades of applications that are waiting to be scheduled for all tenants on this site. Upgrades may still be forced using the force-upgrades action.

Setting this to 'true' allows a site to automatically unseal as soon as a majority of nodes in the local cluster is present. It does not require connectivity to the control-tower in order to unseal.

It should only be used when no sensitive data is stored at sites since it becomes more susceptible to intrusion through physical access. For sites with only one host, a stolen host will be able to unseal the crypto state without accessing the control tower and cannot be blocked from doing so. This option should be used with some care. Allowing local-unseal on one site will potentially expose the communication to other sites as well since the same crypto keys are used to communicate updates. All keys should be rotated if a breach is suspected.

• best-effort: Use TPM or HSM if present and functional.
• require: Require TPM or HSM, fail on initial startup if neither is present or working. Issue tpm-protection-unavailable if configured to require after initial startup and neither TPM nor HSM works.
• never: Do not use TPM or HSM to protect the sealkey.

Controls whether TPM or HSM is used to protect the sealkey.

• treat-as-normal: Temporarily lost connection to this site is considered ok, but during normal operation the site will be connected.
  Application deployment attempts, while being disconnected, will stay in oper-status deploying until the connection has been re-established.
• treat-as-expected: The connection to this site is transient or volatile and it is considered expected behavior. Typically, the site might be non-operative during some periods.
  Application deployment attempts, while being disconnected, is not considered to be an error and will hence not effect nor block the overall deployment of an application, unless the application deployment is for canary sites. In this case treat-as-expected has no effect.
  Any deployment attempts to sites that are disconnected and configured with treat-as-expected behavior will be marked as skipped-disconnected in the deployment status for the corresponding application version.
• treat-as-error: The connection to this site is required and any lost connection is considered an error and will be alerted.
  Application deployment attempts, while being disconnected, will stay in oper-status deploying until the connection has been re-established.

EXPERIMENTAL - Might be removed or changed in future releases.

When set to 'true', all hosts in the site will attempt to keep their system clocks synchronized with the Control Tower instance, but only when Chrony is not already synchronized with another reliable source.

This requires that the Chrony time synchronization service is installed and running on the hosts. The Chrony daemon must be configured to accept external clock updates on the socket tsq.sock. Ensure that the Chrony configuration contains:

refclock SOCK /run/chrony/tsq.sock refid TSQ

With synchronization enabled, each host will periodically check (every 30 minutes) the status of the local Chrony daemon. If Chrony reports that it is not synchronized with any other source, the host will query the Control Tower for the current time and provide the retrieved value as an external reference to Chrony, which then adjusts the system clock accordingly.

Valid when: ../type != "edge"

The addresses other sites should use when connecting to this site. By default it will be the known addresses of all hosts in this site.

Valid when: ../type = "edge"

If a particular site needs to override the parents inter-cluster-address, configure that address here

Reference to the system resource profile used for this site. This profile may be overridden by system resource profiles configured on specific hosts.

• disabled: Ingress is not allowed on this site. Service instances requiring an ingress address will not be started.
• dhcp: Ingress allocation is performed by querying an external DHCP server. The DHCP server must support DHCP client identifier option and be reachable from any host on the edge site.
  The DHCP client identifier used to request an ingress address for a service instance is of the form tenant:application:service-index, unless the ingress-dhcp-client-id-site-prefix parameter is configured.
• pool: Allocation is performed by system from a configured ingress-ipv4-address-ranges pool of addresses, sitewide or per network interface.
• external: Experimental.
  EXPERIMENTAL - Might be removed in future releases.
• port-forward: Forward ports from the main IP address on the selected interface. There must be no overlap in ports forwarded for different services on the same host. Ports used by supd itself may not be forwarded (53/tcp, 53/udp, 4646/tcp, 4653/tcp, 4653/udp, 4664/tcp, 4668/tcp, 4848/tcp, 4849/tcp, 8137/tcp, 51820/udp).

Must be true: . != 'pool' or ../ingress-ipv4-address-ranges or ../hosts/network-interfaces/ingress-ipv4-address-ranges

Valid when: not(ingress-allocation-method) or ingress-allocation-method = 'dhcp'

Valid when: not(ingress-allocation-method) or ingress-allocation-method = 'pool'

If ingress-allocation-method is set to pool and this parameter is configured, then the system will allocate ingress IPv4 addresses from this configured range. It is the responsibility of the site provider to make sure these address blocks are properly routed to this site.

This parameter controls the sitewide ingress IP allocation pool. The sitewide pool is used to allocate ingress IP addresses on any interface on any host within the site, if it does not have a specific per interface ingress IP allocation pool configured. It means that the addresses within the sitewide pool must be routable to any host within the site, except the hosts that have per interface ingress IP allocation pools configured.

Valid when: not(../ingress-allocation-method) or ../ingress-allocation-method = 'dhcp'

Normally this parameter should not be configured.

By default the DHCP client identifier used to request an ingress address for a service instance is of the form tenant:application:service-index. However, this means that a single DHCP server may not serve ingress addresses for multiple sites because this identifier is not longer unique in this case. While rarely the case in practice, this behaviour may be changed by configuring this parameter.

When this parameter is not empty, the DHCP client identifier for a service instance is of the form prefix:tenant:application:service-index.

• ipv4-address-range: Range of IPv4 addresses which does not have to be a proper subnet, for example to express a range of addresses available for allocation.
  For example, 192.0.2.100-192.0.2.150.
• ipv4-prefix: Represents an IPv4 address prefix. Must be on the form <ipv4-address>/<len> where <len> is the prefix length.
• ipv4-address

Valid when: ../type = 'edge'

By default access to Avassa services on edge sites is restricted to localhost and other endpoints required for normal operation, such as API access for applications and registry access within cluster. This configuration enables access to Avassa services from additional IP addresses or ranges of IP addresses.

Reference to the a site profile applied to this site.

Wrap the sealkey shares with a key held in an external key store. At boot the site asks the key store to unwrap them and unseals without operator interaction. A key-store failure is an error, never a silent downgrade to TPM or plaintext protection.

Free form name of the site.

• edge
• top

Map of string keys and values that can be used to organize and categorize (scope and select) sites.

In addition to the configured labels, the following labels are added by the system to the operational state, which means that they are available for matching.

• system/name: contains the value of the site's name
• system/type: contains the value of the site's type

A label name consists of an optional prefix followed by /, followed by a name segment. The optional prefix is a DNS host name (must match inet:domain-name). The name segment must match ava:name.

The prefix system is used for labels assigned by the system.

Label names without prefixes are reserved for application owners.

For example:

• system/controller
• example.com/location.city
• example.com/color
• color

When a site is quarantined no replication of secrets will be replicated. The site will not be allowed to authenticate towards its parent, and cannot auto-unseal.

Block upgrades of applications that are waiting to be scheduled for all tenants on this site. Upgrades may still be forced using the force-upgrades action.

Setting this to 'true' allows a site to automatically unseal as soon as a majority of nodes in the local cluster is present. It does not require connectivity to the control-tower in order to unseal.

It should only be used when no sensitive data is stored at sites since it becomes more susceptible to intrusion through physical access. For sites with only one host, a stolen host will be able to unseal the crypto state without accessing the control tower and cannot be blocked from doing so. This option should be used with some care. Allowing local-unseal on one site will potentially expose the communication to other sites as well since the same crypto keys are used to communicate updates. All keys should be rotated if a breach is suspected.

• best-effort: Use TPM or HSM if present and functional.
• require: Require TPM or HSM, fail on initial startup if neither is present or working. Issue tpm-protection-unavailable if configured to require after initial startup and neither TPM nor HSM works.
• never: Do not use TPM or HSM to protect the sealkey.

Controls whether TPM or HSM is used to protect the sealkey.

• treat-as-normal: Temporarily lost connection to this site is considered ok, but during normal operation the site will be connected.
  Application deployment attempts, while being disconnected, will stay in oper-status deploying until the connection has been re-established.
• treat-as-expected: The connection to this site is transient or volatile and it is considered expected behavior. Typically, the site might be non-operative during some periods.
  Application deployment attempts, while being disconnected, is not considered to be an error and will hence not effect nor block the overall deployment of an application, unless the application deployment is for canary sites. In this case treat-as-expected has no effect.
  Any deployment attempts to sites that are disconnected and configured with treat-as-expected behavior will be marked as skipped-disconnected in the deployment status for the corresponding application version.
• treat-as-error: The connection to this site is required and any lost connection is considered an error and will be alerted.
  Application deployment attempts, while being disconnected, will stay in oper-status deploying until the connection has been re-established.

EXPERIMENTAL - Might be removed or changed in future releases.

When set to 'true', all hosts in the site will attempt to keep their system clocks synchronized with the Control Tower instance, but only when Chrony is not already synchronized with another reliable source.

This requires that the Chrony time synchronization service is installed and running on the hosts. The Chrony daemon must be configured to accept external clock updates on the socket tsq.sock. Ensure that the Chrony configuration contains:

refclock SOCK /run/chrony/tsq.sock refid TSQ

With synchronization enabled, each host will periodically check (every 30 minutes) the status of the local Chrony daemon. If Chrony reports that it is not synchronized with any other source, the host will query the Control Tower for the current time and provide the retrieved value as an external reference to Chrony, which then adjusts the system clock accordingly.

Valid when: ../type != "edge"

The addresses other sites should use when connecting to this site. By default it will be the known addresses of all hosts in this site.

Valid when: ../type = "edge"

If a particular site needs to override the parents inter-cluster-address, configure that address here

Reference to the system resource profile used for this site. This profile may be overridden by system resource profiles configured on specific hosts.

• disabled: Ingress is not allowed on this site. Service instances requiring an ingress address will not be started.
• dhcp: Ingress allocation is performed by querying an external DHCP server. The DHCP server must support DHCP client identifier option and be reachable from any host on the edge site.
  The DHCP client identifier used to request an ingress address for a service instance is of the form tenant:application:service-index, unless the ingress-dhcp-client-id-site-prefix parameter is configured.
• pool: Allocation is performed by system from a configured ingress-ipv4-address-ranges pool of addresses, sitewide or per network interface.
• external: Experimental.
  EXPERIMENTAL - Might be removed in future releases.
• port-forward: Forward ports from the main IP address on the selected interface. There must be no overlap in ports forwarded for different services on the same host. Ports used by supd itself may not be forwarded (53/tcp, 53/udp, 4646/tcp, 4653/tcp, 4653/udp, 4664/tcp, 4668/tcp, 4848/tcp, 4849/tcp, 8137/tcp, 51820/udp).

Must be true: . != 'pool' or ../ingress-ipv4-address-ranges or ../hosts/network-interfaces/ingress-ipv4-address-ranges

Valid when: not(ingress-allocation-method) or ingress-allocation-method = 'dhcp'

Valid when: not(ingress-allocation-method) or ingress-allocation-method = 'pool'

If ingress-allocation-method is set to pool and this parameter is configured, then the system will allocate ingress IPv4 addresses from this configured range. It is the responsibility of the site provider to make sure these address blocks are properly routed to this site.

This parameter controls the sitewide ingress IP allocation pool. The sitewide pool is used to allocate ingress IP addresses on any interface on any host within the site, if it does not have a specific per interface ingress IP allocation pool configured. It means that the addresses within the sitewide pool must be routable to any host within the site, except the hosts that have per interface ingress IP allocation pools configured.

Valid when: not(../ingress-allocation-method) or ../ingress-allocation-method = 'dhcp'

Normally this parameter should not be configured.

By default the DHCP client identifier used to request an ingress address for a service instance is of the form tenant:application:service-index. However, this means that a single DHCP server may not serve ingress addresses for multiple sites because this identifier is not longer unique in this case. While rarely the case in practice, this behaviour may be changed by configuring this parameter.

When this parameter is not empty, the DHCP client identifier for a service instance is of the form prefix:tenant:application:service-index.

• ipv4-address-range: Range of IPv4 addresses which does not have to be a proper subnet, for example to express a range of addresses available for allocation.
  For example, 192.0.2.100-192.0.2.150.
• ipv4-prefix: Represents an IPv4 address prefix. Must be on the form <ipv4-address>/<len> where <len> is the prefix length.
• ipv4-address

Valid when: ../type = 'edge'

By default access to Avassa services on edge sites is restricted to localhost and other endpoints required for normal operation, such as API access for applications and registry access within cluster. This configuration enables access to Avassa services from additional IP addresses or ranges of IP addresses.

Reference to the a site profile applied to this site.

Wrap the sealkey shares with a key held in an external key store. At boot the site asks the key store to unwrap them and unseals without operator interaction. A key-store failure is an error, never a silent downgrade to TPM or plaintext protection.

Free form name of the site.

• edge
• top

Map of string keys and values that can be used to organize and categorize (scope and select) sites.

In addition to the configured labels, the following labels are added by the system to the operational state, which means that they are available for matching.

• system/name: contains the value of the site's name
• system/type: contains the value of the site's type

A label name consists of an optional prefix followed by /, followed by a name segment. The optional prefix is a DNS host name (must match inet:domain-name). The name segment must match ava:name.

The prefix system is used for labels assigned by the system.

Label names without prefixes are reserved for application owners.

For example:

• system/controller
• example.com/location.city
• example.com/color
• color

When a site is quarantined no replication of secrets will be replicated. The site will not be allowed to authenticate towards its parent, and cannot auto-unseal.

Block upgrades of applications that are waiting to be scheduled for all tenants on this site. Upgrades may still be forced using the force-upgrades action.

Setting this to 'true' allows a site to automatically unseal as soon as a majority of nodes in the local cluster is present. It does not require connectivity to the control-tower in order to unseal.

It should only be used when no sensitive data is stored at sites since it becomes more susceptible to intrusion through physical access. For sites with only one host, a stolen host will be able to unseal the crypto state without accessing the control tower and cannot be blocked from doing so. This option should be used with some care. Allowing local-unseal on one site will potentially expose the communication to other sites as well since the same crypto keys are used to communicate updates. All keys should be rotated if a breach is suspected.

• best-effort: Use TPM or HSM if present and functional.
• require: Require TPM or HSM, fail on initial startup if neither is present or working. Issue tpm-protection-unavailable if configured to require after initial startup and neither TPM nor HSM works.
• never: Do not use TPM or HSM to protect the sealkey.

Controls whether TPM or HSM is used to protect the sealkey.

• treat-as-normal: Temporarily lost connection to this site is considered ok, but during normal operation the site will be connected.
  Application deployment attempts, while being disconnected, will stay in oper-status deploying until the connection has been re-established.
• treat-as-expected: The connection to this site is transient or volatile and it is considered expected behavior. Typically, the site might be non-operative during some periods.
  Application deployment attempts, while being disconnected, is not considered to be an error and will hence not effect nor block the overall deployment of an application, unless the application deployment is for canary sites. In this case treat-as-expected has no effect.
  Any deployment attempts to sites that are disconnected and configured with treat-as-expected behavior will be marked as skipped-disconnected in the deployment status for the corresponding application version.
• treat-as-error: The connection to this site is required and any lost connection is considered an error and will be alerted.
  Application deployment attempts, while being disconnected, will stay in oper-status deploying until the connection has been re-established.

EXPERIMENTAL - Might be removed or changed in future releases.

When set to 'true', all hosts in the site will attempt to keep their system clocks synchronized with the Control Tower instance, but only when Chrony is not already synchronized with another reliable source.

This requires that the Chrony time synchronization service is installed and running on the hosts. The Chrony daemon must be configured to accept external clock updates on the socket tsq.sock. Ensure that the Chrony configuration contains:

refclock SOCK /run/chrony/tsq.sock refid TSQ

With synchronization enabled, each host will periodically check (every 30 minutes) the status of the local Chrony daemon. If Chrony reports that it is not synchronized with any other source, the host will query the Control Tower for the current time and provide the retrieved value as an external reference to Chrony, which then adjusts the system clock accordingly.

Valid when: ../type != "edge"

The addresses other sites should use when connecting to this site. By default it will be the known addresses of all hosts in this site.

Valid when: ../type = "edge"

If a particular site needs to override the parents inter-cluster-address, configure that address here

Reference to the system resource profile used for this site. This profile may be overridden by system resource profiles configured on specific hosts.

• disabled: Ingress is not allowed on this site. Service instances requiring an ingress address will not be started.
• dhcp: Ingress allocation is performed by querying an external DHCP server. The DHCP server must support DHCP client identifier option and be reachable from any host on the edge site.
  The DHCP client identifier used to request an ingress address for a service instance is of the form tenant:application:service-index, unless the ingress-dhcp-client-id-site-prefix parameter is configured.
• pool: Allocation is performed by system from a configured ingress-ipv4-address-ranges pool of addresses, sitewide or per network interface.
• external: Experimental.
  EXPERIMENTAL - Might be removed in future releases.
• port-forward: Forward ports from the main IP address on the selected interface. There must be no overlap in ports forwarded for different services on the same host. Ports used by supd itself may not be forwarded (53/tcp, 53/udp, 4646/tcp, 4653/tcp, 4653/udp, 4664/tcp, 4668/tcp, 4848/tcp, 4849/tcp, 8137/tcp, 51820/udp).

Must be true: . != 'pool' or ../ingress-ipv4-address-ranges or ../hosts/network-interfaces/ingress-ipv4-address-ranges

Valid when: not(ingress-allocation-method) or ingress-allocation-method = 'dhcp'

Valid when: not(ingress-allocation-method) or ingress-allocation-method = 'pool'

If ingress-allocation-method is set to pool and this parameter is configured, then the system will allocate ingress IPv4 addresses from this configured range. It is the responsibility of the site provider to make sure these address blocks are properly routed to this site.

This parameter controls the sitewide ingress IP allocation pool. The sitewide pool is used to allocate ingress IP addresses on any interface on any host within the site, if it does not have a specific per interface ingress IP allocation pool configured. It means that the addresses within the sitewide pool must be routable to any host within the site, except the hosts that have per interface ingress IP allocation pools configured.

Valid when: not(../ingress-allocation-method) or ../ingress-allocation-method = 'dhcp'

Normally this parameter should not be configured.

By default the DHCP client identifier used to request an ingress address for a service instance is of the form tenant:application:service-index. However, this means that a single DHCP server may not serve ingress addresses for multiple sites because this identifier is not longer unique in this case. While rarely the case in practice, this behaviour may be changed by configuring this parameter.

When this parameter is not empty, the DHCP client identifier for a service instance is of the form prefix:tenant:application:service-index.

• ipv4-address-range: Range of IPv4 addresses which does not have to be a proper subnet, for example to express a range of addresses available for allocation.
  For example, 192.0.2.100-192.0.2.150.
• ipv4-prefix: Represents an IPv4 address prefix. Must be on the form <ipv4-address>/<len> where <len> is the prefix length.
• ipv4-address

Valid when: ../type = 'edge'

By default access to Avassa services on edge sites is restricted to localhost and other endpoints required for normal operation, such as API access for applications and registry access within cluster. This configuration enables access to Avassa services from additional IP addresses or ranges of IP addresses.

Reference to the a site profile applied to this site.