System Site profiles

The name of the profile.

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.

• 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).

The name of the profile.

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.

• 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).

The name of the profile.

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.

• 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).