Package CloudManagement

URI: CloudManagement

Description: Model of cloud hosting and automated management.

R-Ct

Finds a solo Container.

R-CtDS

Finds a Container that stores a copy of Data (which is actually not allowed).

R-CtH

Finds a container provisioned by a Host.

R-CtHaH

Finds a Container provisioned by a Host that is above another Host.

R-CtHhPH

Finds a Container provisioned by a Host that has a PhysicalHost.

R-DCCM

Finds a Data Centre with a Cluster on which is provisioned a Pod management Master node.

R-DCCMCAP

Finds a process controlling a data centre hosting a K8s master node running a K8s API server and Ingress proxy.

R-DCCt

Finds a Container managed directly by a Data Centre.

R-DCMW

Finds a K8s Master and Worker on the same (cluster) Host in a Data Centre.

R-DCPHM

Finds a Cloud (e.g. K8s) Master node whose physical host is in a Data Centre.

R-DCPHW

Finds a Cloud (K8s) Worker whose physical host is in a Data Centre.

R-HCt

Finds a host provisioned by a container.

R-HumPC

Finds a Container running a Process managed by a Human.

R-KIP

Finds an Ingress proxy mediating access to a service.

R-KPxCaaSI

Finds a Client using for authentication a Service that runs in a Container, whose Pod is connected via a Subnet to a K8 Master that runs a K8s Ingress proxy.

R-KPxCazSI

Finds a Client using for authorization a Service that runs in a Container, whose Pod is connected via a Subnet to a K8 Master that runs a K8s Ingress proxy.

R-KPxCLnSA

Finds a Client using a Remote Acces Service that runs in and controls a Container, whose Pod is connected via a Subnet to a K8S Master that runs a K8s API Server.

R-KPxCuScP

Finds a Pod managed by K8S or equivalent, hosting an unprivileged service in a Container, which controls another service accessed by a client. This means the client will need to access to Service in its Container for authentication purposes.

R-KPxCuuSI

Finds a Client using a Service that runs in a Container, whose Pod is connected via a Subnet to a K8 Master that runs a K8s Ingress proxy.

R-KPxMLnSA

Finds a Client using a Remote Access Service that runs on and controls a K8s Master node, connected to a Subnet and running a K8s API Server.

R-KPxWLnSA

Finds a Client using a Remote Access Service that runs on and controls a K8s Worker node, connected via a Subnet to a Master that runs a K8s API Server.

R-MWHLS

Finds K8s Master and Worker nodes on the same (cluster) host, and connected to the same subnet.

R-MWPodLS2

Finds a Pod running on a K8s Worker connected via a Logical Subnet to a K8s Master, which can also access an overlay on the Logical Subnet.

R-Pod

Finds a solo Pod.

R-PodCnD

Finds Data stored on a Container provisioned by a Pod.

R-PodCnP

Finds a Process hosted by a Container provisioned by a Pod.

R-PodCnPD

Finds a Container running a Process that handles Data stored on the associated Pod.

R-PodDCC

Finds a Pod managed by a Data Centre that has a Cluster.

R-PodDCMC

Finds a K8s Pod managed by a Data Centre that has a Cluster with a K8s Master.

R-PodHaH

Finds a Pod provisioned by a Host that is above another Host.

R-PodHhPH

Finds a Pod provisioned by a Host that has a PhysicalHost.

R-PodP

Finds a Pod containing a Process.

MP-Ct

Finds a solo Container.

MP-CtDS

Finds a Container that stores a copy of Data (which is actually not allowed).

MP-CtHaH

Finds a Container provisioned by a Host that is above another Host.

MP-CtHhPH

Finds a Container provisioned by a Host that has a PhysicalHost.

MP-CtH-iP

Finds a container provisioned by a Host that is not a Pod.

MP-DCCM-A

Finds a Data Centre with a Cluster on which is provisioned a Pod management Master node that does not yet host an API Server.

MP-DCCMCAP

Finds a process controlling a data centre hosting a K8s master node running a K8s API server and Ingress proxy.

MP-DCCM-P

Finds a Data Centre with a Cluster on which is provisioned a Pod management Master node that does not yet host an Ingress reverse proxy.

MP-DCCt-Pod

Finds a Container managed directly by a Data Centre and not via a Pod.

MP-DCMW-LS

Finds a K8s Master and Worker on the same (cluster) Host in a Data Centre, where the Master and Worker are not on any common subnet.

MP-DCPHM

Finds a K8s Master whose physical host is in a Data Centre.

MP-DCPHW

Finds a K8s Worker whose physical host is in a Data Centre.

MP-DCPS-Pod

Finds a Process hosted directly on a Data Centre, but not contained by a Pod managed by the Data Centre.

MP-DCVHC

Finds a DataCentre containing a Cluster, and a Virtual Host.managed by the Data Centre rather than being provisioned on a Host.

MP-HCt

Finds a host provisioned by a container.

MP-Hum-iH-AC

Finds a human remotely managing a host but lacking a suitable connection to its management service.

MP-Hum-iHRAS

Finds a human managing but not interacting with a host that is not a Pod and has a root privileged remote access service.

MP-Hum-iSH-LnS

Finds a Human managing but not interacting with a Shell Host, where there is no process controlling the host.

MP-HumPC-Hu

Finds an unmanaged Container of a Process managed by a Human.

MP-KIP-S

Finds an Ingress proxy mediating access to a service, but not controlled by any other process.

MP-KPxCaaSI

Finds a Pod managed by K8S or equivalent, hosting an unprivileged service in a Container, accessed for authentication purposes by a client from outside the K8S cluster.

MP-KPxCazSI

Finds a Pod managed by K8S or equivalent, hosting an unprivileged service in a Container, accessed for authorization purposes by a client from outside the K8S cluster.

MP-KPxCLnSA

Finds a Pod managed by K8S or equivalent, hosting a remote access service running in and controlling a Container, and used by a client from outside the K8S cluster.

MP-KPxCuScP

Finds a Pod managed by K8S or equivalent, hosting an unprivileged service in a Container, which controls another service accessed by a client from outside the K8S cluster.

MP-KPxCuuSI

Finds a Pod managed by K8S or equivalent, hosting an unprivileged service in a Container, accessed by a client from outside the K8S cluster.

MP-KPxMLnSA

Finds a Remote Access Service that runs on and controls a K8s Master node that runs a K8s API Server, connected via a Subnet to a K8s Worker cluster, and used by a client from outside the K8S cluster.

MP-KPxWLnSA

Finds a Remote Access Service that runs on and controls a K8s Worker node, connected via a Subnet to a Master that runs a K8s API Server, and used by a client from outside the K8S cluster.

MP-MWHLS

Finds K8s Master and Worker nodes on the same (cluster) host, and connected to the same subnet.

MP-MWPodLS2

Finds a Pod running on a K8s Worker connected via a Logical Subnet to a K8s Master, which can also access an overlay on the Logical Subnet.

MP-Pc-hSHLnS

Finds a Process controlling a Shell Host that runs a Remote Access Service, but the Shell Host is not a Pod and not the Process host.

MP-PodCnD

Finds Data stored on a Container provisioned by a Pod.

MP-PodCnP

Finds a Process hosted by a Container provisioned by a Pod.

MP-PodCnPD

Finds a Container running a Process that handles Data stored on the associated Pod.

MP-PodDCC-M

Finds a Pod managed by a Data Centre that has a Cluster, but there is no Master node provisioned on the Cluster.

MP-PodDCMC-W-H

Finds a K8s Pod with no Host managed by a Data Centre that has a Cluster with a K8s Master, where the Data Centre does not yet have a K8s Worker cluster.

MP-PodHaH

Finds a Pod provisioned by a Host that is above another Host.

MP-PodHhPH

Finds a Pod provisioned by a Host that has a PhysicalHost.

MP-PodMP

Finds a solo Pod.

MP-PodP-Cn

Finds a Pod containing a Process but with no intervening Container.

MP-SHVH

Finds a Virtual Host provisioned on a Simple Host that is not a Pod.

MP-VH-LnS

Finds a Virtual Host that is not controlled by any process.

CP-Ct+iC

Finds a solo Container, and adds a self-referential link marking it as such.

CP-PodMP+iP

Finds a solo Pod, and adds a self-referential link marking it as such.

CP-DCVHC+p

Finds a Virtual Host provisioned by a Data Centre but not yet by any host, and adds relationships to the Data Centre cluster.

CP-DCPS-Pod+Pod

Finds a serverless Process hosted directly on a data centre but not via a Pod, and adds a Pod managed by the Data Centre to contain the Process.

CP-DCCt-Pod+Pod

Finds a Container managed directly by a Data Centre and not via a Pod, and inserts the missing Pod.

CP-PodP-Cn+Cn

Finds a Pod containing a Process, and inserts a Container for the Process.

CP-PodCnP+c

Finds a Process hosted by a Container provisioned by a Pod, and ensures there is a contains relationship between the Pod and the Process.

CP-PodCnD+s

Finds Data stored on a Container provisioned by a Pod, and makes the Pod store the Data.

CP-PodCnPD+s

Finds a Container running a Process that handles Data stored on the associated Pod, and adds a link to say the Container stores the data. Since the Pod already stores the data, this link means a service on the Pod (or possibly its host) is used to provide a data volume accessed as local storage from the Container.

CP-DCPHM+p

Finds a K8s Master whose physical host is in a Data Centre, and asserts that it is managed by the data centre.

CP-DCPHW+p

Finds a K8s Worker whose physical host is in a Data Centre, and asserts that it is managed by the data centre.

CP-PodDCC-M+M

Finds a Pod managed by a Data Centre that has a Cluster, but there is no Cloud Master node provisioned on the Cluster, and adds the Cloud Master.

CP-PodDCMC-W-H+W

Finds a K8s Pod with no Host managed by a Data Centre that has a Cluster with a K8s Master, where the Data Centre does not yet have a K8s Worker cluster, and adds one to host the Pod.

CP-PodHaH+a

Finds a Pod provisioned by a Host that is above another Host, and asserts that the Pod is also above the second Host.

CP-PodHhPH+hPH

Finds a Pod provisioned by a Host that has a PhysicalHost, and asserts that the Pod has the same PhysicalHost.

CP-CtHaH+a

Finds a Container provisioned by a Host that is above another Host, and asserts that the Container is also above the second Host.

CP-CtHhPH+hPH

Finds a Container provisioned by a Host that has a PhysicalHost, and assets that the Container has the same PhysicalHost.

CP-DCMW-LS+VX

Finds a K8s Master and Worker on the same (cluster) Host in a Data Centre, where the Master and Worker are not on any common subnet, and adds a VXLAN for this provided by the Data Centre.

CP-MWHLS+CIP

Finds K8s Master and Worker nodes on the same (cluster) host, and connected to the same subnet, and adds an ClusterIP overlay network to which the Master is connected.

CP-MWPodLS2+c

Finds a Pod running on a K8s Worker connected via a Logical Subnet to a K8s Master, which can also access an overlay on the Logical Subnet, and connects the Pod to the overlay subnet.

CP-DCCM-A+A

Finds a Data Centre with a Cluster on which is provisioned a Pod management Master node that is not hosting a Pod management API Server, and adds one.

CP-DCCM-P+P

Finds a Data Centre with a Cluster on which is provisioned a Pod management Master node that is not hosting a Pod management Ingress reverse proxy, and adds one.

CP-DCCMCAP+c

Finds a process controlling a data centre hosting a K8s master node running a K8s API server and Ingress proxy, and adds control links from the process to the two services.

CP-HumPC-Hu+m

Finds an unmanaged Container of a Process managed by a Human, and makes the Human manager also of the Container.

CP-VH-LnS+LnS

Adds a login service to a headless Virtual Host without one.

CP-Hum-iSH-LnS+LnS

Finds a Human managing but not interacting with a Shell Host, where there is no process controlling the host, and adds a login service to allow remote management.

CP-Pc-hSHLnS+c

Finds a Process controlling a Shell Host that runs a Remote Access Service, but the Shell Host is not a Pod and not the Process host, and adds a link specifying that the Process controls the RAS.

CP-Hum-iHRAS+i

Finds a human managing but not interacting with a host that is not a Pod and has a root privileged remote access service, and adds a link to say the human interacts with the desktop service.

CP-KPxMLnSA+uu

CP-KPxWLnSA+uu

Finds a Remote Access Service that runs on and controls a K8s Worker node, connected via a Subnet to a Master that runs a K8s API Server, and used by a client from outside the K8S cluster, and infers access is mediated by the API Server.

CP-KPxCLnSA+uu

Finds a Pod managed by K8S or equivalent, hosting a remote access service running in and controlling a Container, and used by a client from outside the K8S cluster, and infers access is mediated by the API Server.

CP-KPxCaaSI+aa

Finds a Pod managed by K8S or equivalent, hosting an unprivileged service in a Container, accessed for authentication purposes by a client from outside the K8S cluster, and infers access is mediated by the Ingress proxy.

CP-KPxCazSI+az

Finds a Pod managed by K8S or equivalent, hosting an unprivileged service in a Container, accessed for authorization purposes by a client from outside the K8S cluster, and infers access is mediated by the Ingress proxy.

CP-KPxCuuSI+uu

Finds a Pod managed by K8S or equivalent, hosting an unprivileged service in a Container, accessed by a client from outside the K8S cluster, and infers access is mediated by the Ingress proxy.

CP-KPxCuScP+aa

Finds a Pod managed by K8S or equivalent, hosting an unprivileged service in a Container, which controls another service accessed by a client from outside the K8S cluster, and infers access by the client to the controlling service is mediated by the Ingress proxy.

CP-KIP-S+c

Finds an Ingress proxy mediating access to a service, but not controlled by any other process, and makes it delegate authentication to the back end service (the service controls the Ingress proxy).

DF.A.PDF.6.2

Loss of availability from suspending the flow of unauthentic data Data from FlowsFrom to Process: if a contingency plan is used in which the flow of Data between FlowsFrom to Process is disabled if the data was subject to malicious tampering, then the flow of data Data from FlowsFrom to Process will become unavailable.

H.A.CVHHDC.0

SLA constrained virtual host Host becomes unavailable: if clusterable virtual host Host running in data centre DataCentre becomes overloaded, and it is limited by an SLA from scaling up its use of resources at DataCentre, then it may become unavailable.

H.E.CtDS.9

Data Data cannot be stored persistently in Container Container: host Container is a Container, which cannot retain persistent state internally.

H.E.CtH-iP.9

Container Container cannot be provisioned on host Host: a Container can only be provisioned by a Pod, which Host is not.

H.E.HCt.9

Host Host cannot be provisioned on container Container: Container is a simple host designed to host a packaged, stateless service, so cannot be used to provision host Host.

H.E.SHVH.9

Hosting error for virtual host VirtualHost: device SimpleHost is a specialised host that cannot provision virtual host VirtualHost. Either remove VirtualHost, or move its provisionedBy relationship to a more general purpose host.

H.O.CVHHHoDC.0

Effect of overload at Host on SHost: if virtual host Host is overloaded, and allowed to scale up via elastic hosting on cluster SHost, the overload may propagate to SHost if not managed to prevent this by a Data Centre.

Hu.E.Hum-iH-AC.9

User HostManager unable to manage device Host: since HostManager manages but does not interactWith Host, they must manage the device remotely. However this means they should connect to its login service from an authentication client on an interactive host, directly or via some other host. This is not the case, so HostManager may lack an interactive host device on which they can run a suitable client.

P.E.HuiHP.9

Cannot auto-provision interactive process Process: since process Process is used interactively by user Human, it does not make sense for it to be auto-provisioned. Deselect the control and use other measures instead, or remove the interaction between Human and Process .

(empty)

CSG-AutomatedHostFaultRecovery	Faulty instances of the virtual device *Host* can be detected by monitoring, halted, and a replacement provisioned automatically.
CSG-AutomatedProcessFaultRecovery	Faulty instances of the process *Process* can be detected by monitoring, halted, and a replacement provisioned automatically.
CSG-AutoProvisioningProcessError	Automated provisioning is specified at process *Process* but this is an inappropriate control selection because user *Human* is using the process interactively.
CSG-AutoSuspendCorruptDataFlow	The flow of data *Data* from *FlowsFrom* to *FlowsTo* can be automatically disabled to prevent corrupt or malicious content (including malware) from disrupting the receipient *FlowsTo*. This strategy represents a contingency plan, which can be used to reduce risk from some threats but it also triggers other threats representing possible side effects, depending on how likely it is that the contingency plan will need to be activated.
CSG-AutoSuspendCorruptDataFlow-Implementation-Runtime	The flow of data *Data* from *FlowsFrom* to *FlowsTo* has been automatically disabled to prevent corrupt or malicious content (including malware) from disrupting the receipient *FlowsTo. This strategy represents activation of a contingency plan at runtime, and can be enabled to discover what effect this would have on risk levels, allowing this to be used for decision support calculations. Activation at runtime requires FlowsTo* to be managed by a suitable adaptation framework. The Disabled Data Flow control should be deselected if and when the flow of data is enabled once again.
CSG-AutoSuspendExcessiveClientAccess	Access to service *Service* by client *Client* may be automatically disabled to prevent the service forwarding excessive requests or becoming overloaded itself, at the cost of some reduction in availability. This strategy represents a contingency plan, which can be used to reduce risk from some threats but it also triggers other threats representing possible side effects, depending on how likely it is that the contingency plan will need to be activated.
CSG-AutoSuspendExcessiveClientAccess-Implementation-Runtime	Access to service *Service* by client *Client* has been automatically disabled to prevent the service forwarding excessive requests or becoming overloaded itself. This strategy represents activation of a contingency plan at runtime, and can be selected to discover what effect this would have on risk levels, allowing this to be used for decision support calculations. Activation at runtime requires *Service* to be managed by a suitable adaptation framework. The Disable Client Access control should be deselected if and when access by *Client* to *Service* has been enabled once again.
CSG-AutoSuspendSensitiveDataFlow	The sending of data *Data* from *FlowsFrom* to *FlowsTo* can be can be automatically disabled to prevent leaking of data. This strategy represents a contingency plan, which can be used to reduce risk from some threats but it also triggers other threats representing possible side effects, depending on how likely it is that the contingency plan will need to be activated.
CSG-AutoSuspendSensitiveDataFlow-Implementation-Runtime	The sending of data *Data* from *FlowsFrom* to *FlowsTo* has been automatically disabled to prevent leaking of data. This strategy represents activation of a contingency plan at runtime, and can be enabled to discover what effect this would have on risk levels, allowing this to be used for decision support calculations. Activation at runtime requires *FlowsFrom* to be managed by a suitable adaptation framework. The Disabled Data Flow control should be deselected if and when the flow of data is enabled once again.
CSG-AutoSuspendUnauthenticClientAccess	Access to service *Service* by client *Client* may be automatically disabled to prevent authenticated attacks by impersonated clients, at the cost of some reduction in availability. This strategy represents a contingency plan, which can be used to reduce risk from some threats but it also triggers other threats representing possible side effects, depending on how likely it is that the contingency plan will need to be activated.
CSG-AutoSuspendUnauthenticClientAccess-Implementation-Runtime	Access to service *Service* by client *Client* has been automatically disabled to prevent authenticated attacks by impersonated clients. This strategy represents activation of a contingency plan at runtime, and can be selected to discover what effect this would have on risk levels, allowing this to be used for decision support calculations. Activation at runtime requires *Service* to be managed by a suitable adaptation framework. The Disable Client Access control should be deselected if and when access by *Client* to *Service* has been enabled once again.
CSG-AutoSuspendUntrustworthyClientAccess	Access to service *Service* by client *Client* may be automatically disabled to prevent authenticated attacks by compromised clients, at the cost of some reduction in availability. This strategy represents a contingency plan, which can be used to reduce risk from some threats but it also triggers other threats representing possible side effects, depending on how likely it is that the contingency plan will need to be activated.
CSG-AutoSuspendUntrustworthyClientAccess-Implementation-Runtime	Access to service *Service* by client *Client* has been automatically disabled to prevent authenticated attacks by compromised clients. This strategy represents activation of a contingency plan at runtime, and can be selected to discover what effect this would have on risk levels, allowing this to be used for decision support calculations. Activation at runtime requires *Service* to be managed by a suitable adaptation framework. The Disable Client Access control should be deselected if and when access by *Client* to *Service* has been enabled once again.
CSG-ElasticHosting	The (virtual) device *Host* is operating as a cluster, which allows automatic scaling in the number of instances to meet the load placed upon the host. This must be configured in advance, so it is a blocking strategy not a contingency plan or run-time threat response.
CSG-SLAEnforcement	The use of resources by host *Host* are limited to the level specified in a service level agreement with the hosting data centre *DataCentre*.
CSG-SLAEnforcement-Trigger	The use of resources by host *Host* are limited to the level specified in a service level agreement with the hosting data centre *DataCentre*.

AutoDataGovernance	The Process is managed by a data governance framework such as Fybrik, which can modify its behaviour without the intervention of a human manager.
AutoProvisioning	Instances of the (virtual) Host can be automatically provisioned to increase capacity to meet loads from hosted processes or other virtual hosts.
SLA	The host is subject to a service level agreement negotiated with its data centre that places limits on how far it can be elastically scaled up to meet demand.
SLAEnforcement	There is a means to enforce capacity limits for the resources allocated to a virtual host.

Role_APIServer	A reverse proxy providing access to virtual host login and admin functions in a cloud data centre.
Role_CloudMaster	An master node in a virtual cluster supporting automated management of services in the cloud.
Role_CloudWorker	An worker node in a virtual cluster supporting automated management of services in the cloud.
Role_ClusterIP	An overlay network connecting nodes in a virtual cluster supporting automated management of services in the cloud.
Role_Container	A virtual host configured to run a service that can be automatically deployed and managed in the cloud.
Role_Ingress	A reverse proxy providing access to services that are deployed and managed automatically in a cloud data centre.
Role_Pod	A cloud deployment context for one or more Containers, modelled as a type of host.

APIServer	A proxy for running commands on a Container within a K8S or Docker platform or equivalent. Behaves like a login service on a bastion server, providing shell access via a front-end system (the K8s Master Node) to login services on the Containers. It is not itself a login service, as it does not provide shell access on its own host. The default trustworthiness levels are set on the assumption that this asset will be subject to penetration testing by the data centre operator before it is used.
ClusterIP	A subnet implemented by K8S using iptables rules to provide connectivity to Pods and Services using networks connecting their hosts.
Container	A simple virtual host containing software needed to support a packaged process, suitable for deployment via Docker or Kubernetes.
Ingress	A proxy for accessing services running in a Container under a K8S or equivalent platform. The default trustworthiness levels are set on the assumption that this asset will be subject to penetration testing by the data centre operator before it is used.
Master	A VM that forms part of a virtual cluster managed by a framework such as Kubernetes, but is used to host control plane functions of the management framework.
Pod	A virtual host containing support for sharing a virtual network and storage services with one or more Containers.
Worker	A CloudWorker represents a virtual cluster of worker nodes, which is allocated and managed via a framework such as Kubernetes.