Difference between revisions of "SPG:Drafts:Virtualisation Policy"

From EGIWiki
Jump to: navigation, search
 
(46 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Virtual Machines Endorsement Policy =
 
  
As a result of the January 2011 SPG meeting, there is an item to work on a generalisation of the HEPiX Virtual Machines Endorsement Policy document.
+
[[Category:Security Policy_Group (SPG)]]
 +
= Security Policy for the Endorsement and Operation of Virtual Machine Images  =
  
The original HEPiX policy is available at https://edms.cern.ch/document/1080777
+
This draft policy is currently under external review. The text being reviewed may be seen at https://documents.egi.eu/public/ShowDocument?docid=771
  
= New draft text =
+
As a result of the January 2011 SPG meeting, there was an item to work on a generalisation of the HEPiX Virtual Machines Endorsement Policy document.
  
== Policy on the Endorsement and Operations of Virtual Machine Images ==
+
The original HEPiX policy is available at https://edms.cern.ch/document/1080777
  
 
=== Introduction ===
 
=== Introduction ===
  
This document describes the security-related policy requirements for the generation, distribution and operations of virtual machine (VM) images on the Grid.  
+
This document describes the security-related policy requirements for the generation, distribution and operations of virtual machine (VM) images, as part of a trusted computing environment of the IT infrastructure.
  
The aim is to enable VM images to be generated according to best practices and to be both trusted and operated elsewhere.
+
The aim is to enable VM images to be generated according to best practices and to be both trusted and operated elsewhere.
  
This policy does not compel Sites to instantiate images endorsed in accordance with this policy nor limit the rights of a Site to decide to instantiate a VM image generated by any other non-compliant procedures, should they so desire. The Site is still bound by all applicable Grid security policies and is required to consider the security implications of such an action on other Grid participants.  
+
This policy does not compel resource centres to instantiate images endorsed in accordance with this policy. Should a resource centre decide to instanciate a VM image generated by any other non-compliant procedures, that resource centre is still bound by all applicable security policies and is required to consider the security implications of such an action on other participants.  
  
 
=== Definitions ===
 
=== Definitions ===
  
 
The following terms are defined.  
 
The following terms are defined.  
* '''Endorser''': An individual who confirms that a particular VM image has been produced according to the requirements of this policy and states that the image can be trusted. An Endorser should be one of a limited number of authorised and trusted individuals appointed either by a VO or a Site. The appointing VO or Site must assume responsibility for the actions of the Endorser and must ensure that he/she is aware of the requirements of this policy.
+
* '''Endorser''': A role, held either by an individual or a team, who is responsible for confirming that a particular VM image has been produced according to the requirements of this policy and states that the image can be trusted. An Endorser should be one of a limited number of authorised and trusted individuals appointed either by the infrastructure, a VO or a resource centre. The appointing body must assume responsibility for the actions of the Endorser and must ensure that he/she is aware of the requirements of this policy.
* '''VM operator''': An individual who responsible for security of the VM during its operation phase, from the time it is instantiated, until it is terminated. Typically this addresses individuals with root access on the VM.
+
* '''VM operator''': A role, held either by an individual or a team, who is responsible for the security of the VM during its operation phase, from the time it is instantiated, until it is terminated. Typically this addresses individuals with root access on the VM.
 +
* '''Third party''': An external entity other than the resource centre where the VM is operated.
  
 
=== Use case classification ===
 
=== Use case classification ===
Line 27: Line 28:
 
The current policy document addresses the following use cases.
 
The current policy document addresses the following use cases.
  
==== Endorser: Site, VM operator: Site ====
+
==== Endorser: resource centre, VM operator: resource centre ====
 
 
This class addresses use cases where the VM is provided and operated by the Site.
 
  
Virtualisation is not directly accessible by users. It includes, for example, the use of virtual Grid worker nodes that act in a similar way to real worker nodes.
+
In this class virtualisation is not directly accessible by users. It includes, for example, the use of virtual worker nodes that act in a similar way to real worker nodes.
  
The Site is both the Endorser and the VM operator and is responsible to ensure the compliance of the VM with existing security policies.
+
The resource centre is both the Endorser and the VM operator and is responsible to ensure the compliance of the VM with existing security policies.
  
==== Endorser: Third party, VM operator: Site ====
+
==== Endorser: Third party, VM operator: resource centre ====
This class addresses use cases where the site runs a VM as a site originated VM, as described in 3.1, when this VM is obtained as an untrusted party VM, as described in 3.3.
 
  
In this class, the site is the VM operator, and the trust relationship is established between the Site and the Endorser.
+
In this class, the resource centre is the VM operator, and the trust relationship is established between the resource centre and the Endorser.
  
 
==== Endorser: Third party, VM operator: Third Party ====
 
==== Endorser: Third party, VM operator: Third Party ====
  
This class addresses use cases where the VM is provided and operated by a third party (e.g. end users).
+
In this class, the resource centre runs the VM but is not the VM operator, and the trust relationship is established between:
 
+
* the resource centre and the VM operator
In this class, the Site runs the VM but is not the VM operator, and the trust relationship is established between:
 
* the Site and the VM operator
 
 
* the VM operator and the Endorser (both roles can be combined)
 
* the VM operator and the Endorser (both roles can be combined)
  
The Site is responsible to ensure sufficient traceability in order to enable malicious network activity to be linked with any VM and its VM operator, as defined in the Grid Security Traceability and Logging policy.
+
The resource centre is responsible to ensure sufficient traceability in order to enable malicious network activity to be linked with any VM and its VM operator, as defined in the Security Traceability and Logging policy.
  
The Site has no direct trust relationship with the Endorser and is may decide to apply specific restrictions to control the access of the VM to other resources, including network services.
+
The resource centre has no direct trust relationship with the Endorser and may decide to apply specific restrictions to control the access of the VM to other resources, including network services.
  
 
=== Policy Requirements on the VM Operator ===
 
=== Policy Requirements on the VM Operator ===
  
By acting as an VM Operator you agree to the conditions laid down in this document and other referenced documents, which may be revised from time to time.
+
By acting as a VM Operator you agree to the conditions laid down in this document and other referenced documents, which may be revised from time to time.
  
 
# You are responsible to fulfil all the operational security and incident response requirements expressed in other policies
 
# You are responsible to fulfil all the operational security and incident response requirements expressed in other policies
# You are responsible to ensure that any VM being run has been endorsed and to ensure its compliance with existing security policies, including but not limited to security patching, vulnerability management, incident response, logging and traceability.
+
# You are responsible to ensure that any VM being run is currently endorsed and to ensure its compliance with existing security policies, including but not limited to security patching, vulnerability management, incident response, logging and traceability.
# You are responsible for handling all problems related to the execution of any licensed software in a VM image. You shall ensure that any software run in a VM, complies with applicable license conditions and you shall hold the Site running the image free and harmless from any liability with respect thereto.
+
# You are responsible for handling all problems related to the execution of any licensed software in a VM image. You shall ensure that any software run in a VM, complies with applicable license conditions and you shall hold the resource centre running the image free and harmless from any liability with respect thereto.
 
# You are responsible for contextualising any endorsed image, including credentials and certificates.
 
# You are responsible for contextualising any endorsed image, including credentials and certificates.
  
Line 65: Line 61:
 
By acting as an Endorser you agree to the conditions laid down in this document and other referenced
 
By acting as an Endorser you agree to the conditions laid down in this document and other referenced
 
documents, which may be revised from time to time.
 
documents, which may be revised from time to time.
# You are held responsible by the Grid and by the Sites for checking and confirming that a VM image has been produced according to the requirements of this policy and that there is no known reason, security-related or otherwise, why it should not be trusted.
+
# You are held responsible by the infrastructure and by the resource centres for checking and confirming that a VM image has been produced according to the requirements of this policy and that there is no known reason, security-related or otherwise, why it should not be trusted.
# You recognise that the VM must be generated according to current best practice, the details of which may be documented elsewhere by the Grid. These include but are not limited to:
+
# You recognise that the VM must be generated according to current best practice, the details of which may be documented elsewhere by the infrastructure. These include but are not limited to:
 
## any image generation tool used must be fully patched and up to date;
 
## any image generation tool used must be fully patched and up to date;
## all operating system security patches must be applied to all images and be up to date;
+
## all operating system and other installed software security patches must be applied to all images and be up to date;
 
## images are assumed to be world-readable and as such must not contain any confidential information;
 
## images are assumed to be world-readable and as such must not contain any confidential information;
 
## there should be no installed accounts, host/service private keys, ssh private keys or user credentials of any form in an image;
 
## there should be no installed accounts, host/service private keys, ssh private keys or user credentials of any form in an image;
## images must be configured such that they do not prevent Sites from meeting the finegrained monitoring and control requirements defined in the Grid Security Traceability and Logging policy to allow for security incident response;
+
## images must be configured such that they do not prevent resource centres from meeting the finegrained monitoring and control requirements defined in the Security Traceability and Logging policy to allow for security incident response;
## the image must not prevent Sites from implementing local authorisation and/or policy decisions, e.g. blocking the running of Grid work for a particular user.
+
## the image must not prevent resource centres from implementing local authorisation and/or policy decisions, e.g. blocking the running of work for a particular user.
# You must disclose to the Grid or to any Site on request the procedures and practices you use for checking and endorsing images.
+
# You must disclose to the infrastructure or to any resource centre on request the procedures and practices you use for checking and endorsing images.
# You must provide and maintain an up to date digitally signed list of your currently endorsed images together with the metadata relating to each VM image, as defined in the VM Image Catalogue document.
+
# You must provide and maintain an up to date list of your currently endorsed images together with the metadata relating to each VM image. The related guidelines will be made available by the infrastucture organisation.
# You must keep an auditable history of every image endorsed including the unique identifier, date/time of generation and full list of OS/packages/versions in both the VM Base Image and VO Environment. This must be made available to sites on demand.
+
# Either the list or each individual image's metadata must be digitally signed by the endorser.
# You must remove or revoke images from the list of endorsed images whenever a problem is found, e.g. a new security update is required. This removal must also be recorded locally in your auditable history.
+
# You must keep an auditable history of every image endorsed including the date/time of generation and full list, including exact versions, of installed software and operating system contained in the VM. This must be made available to resource centres on demand.
# You are responsible for handling all problems related to the distribution of any licensed software in a VM image. You shall ensure that any software distributed in a VM image, complies with applicable license conditions and you shall hold the Site running the image free and harmless from any liability with respect thereto.
+
# You must implement a removal or revocation procedure to allow the VM operators to exclude those images which are no longer endorsed. This procedure must be implemented whenever a problem is found, e.g. a new security update is required. This removal must also be recorded locally in your auditable history.
# You must assist the Grid in security incident response and must have a security vulnerability assessment process in place.
+
# You are responsible for handling all issues related to the distribution of any licensed software in a VM image. You shall ensure that any software distributed in a VM image, complies with applicable license conditions and you shall hold the resource centre running the image free and harmless from any liability with respect thereto.
# You recognise that the Grid, the Sites, and/or the VOs reserve the right to block any endorsed image or terminate any instance of a virtual machine and associated user workload for administrative, operational or security reasons.
+
# You must assist the infrastructure in security incident response and must have a security vulnerability patching process in place.
# You recognise that if a Site runs an image which no longer appears on your list of endorsed images, that you are not responsible for any consequences of this beyond the time of your removal of the image from the list
+
# You recognise that the infrastructure, the resource centres, and/or the VOs reserve the right to block any endorsed image or terminate any instance of a virtual machine and associated user workload for administrative, operational or security reasons.
 
+
# You recognise that if a VM operator runs an image which is no longer endorsed, you are not responsible for any consequences of this beyond the time of your removal of the endorsement.
= Issues and discussion =
 
=== Comments from Dave Kelsey (16 June 2011)===
 
Here is an extract from an email I sent to the HEPiX VM working group back on 10th April 2010. I send this just in case it helps in defining our VM classification.
 
 
 
There have been two attempts (AFAIK) to describe the overall model. First in time was the work by the NL BigGrid working group. https://wiki.nbic.nl/images/f/f6/ProgressReport-1.0.pdf
 
 
 
The report defines the following three classes of VM images.
 
* Class 1: Site provided, similar to current worker nodes.
 
* Class 2: From trustworthy sources, running as part of the trusted network fabric.
 
* Class 3: Generated by end-users running in a DMZ.
 
 
 
JSPG at its recent meeting (but without actually considering in the BiGGrid report) defined 3 models as follows:
 
* Model 1: The Computer Centre view. Increase the number of worker nodes by virtualising them. Fully controlled by the Site with full access to the batch system and network file system. Neither the VO nor the User has root access.
 
* Model 2: The VO view. Images produced by a small number of trusted people on behalf of the VO. Similar to some aspects of the Amazon EC2 services and/or the CERNVM project. User probably needs root access to the VM instance to monitor and maintain their environment. This may be OK if the VM does not have access to the site batch system or site file system.
 
* Model 3: Individual users are producing their own images. Difficult to see how this could be done in a trustworthy way except for full containment of the running image.
 
 
 
There is a pretty close match between the two classification schemes, the one difference perhaps being as to whether the image provider has root access to running instances of Class 2/Model 2.
 
 
 
JSPG in its discussions decided to concentrate on model 1 and noted that model 2 needed more discussion to define exactly what it was.
 
 
 
=== Comments from Peter Solagna (27 June 2011)===
 
 
 
==== Definitions and VM types====
 
===== '''VM operator'''=====
 
Does it mean that the VM operator is the entity who started the VM, who could stop it and have root access to the machine? Everyone who has root access to the machine is a Operator, or a user can have root access to the machine, not being its operator? I would explicitly wrote in the definitions who has the root access (or superuser) for the virtual machines and who has not.
 
I agree that the operator has the responsibility to patch/update running machines (that can run for months), but I would share this responsibility with the Endorsers: who should provide an image as up-to-date and patched as it is possible.
 
 
 
===== '''Site originated VM'''=====
 
I would substitute ''"is not directly visible to users"'' with "virtualization is not directly accessible by users". Maybe it is the wrong wording, but I want just to consider in this definition also the case where a user choose the machine he wants to instantiate, from a list of images provided directly by the site (e.g. different o.s.).
 
 
 
===== Point 2, bullet 4 =====
 
''there should be no installed accounts, host/service certificates, ssh keys or user credentials of any form in an image; (Does not apply to all the classes above, needs to be reviewed)''
 
I can't understand the reasons for this rule applied in the different scenarios. I think that ssh-keys are necessary to let the operator or the user access the root account in the VM.
 
 
 
===== Point 2 =====
 
(the numbering restarted after the bullets)<br>
 
''as defined in the VM Image Catalogue document. ''<br>
 
Is the document defined somewhere else? I would add the definition in the glossary.
 
 
 
===== Point 4 =====
 
''You must remove images from the approved list whenever a problem is found, e.g. a new security update is required. This removal must also be recorded locally in your auditable history. ''<br>
 
Should it be ''"list of endorsed images"'' written in point 8?
 
 
 
=== Comments from Riccardo Brunetti (29 June 2011) ===
 
==== Definitions and VM types ====
 
===== '''Globally Unique Identifier'''=====
 
Is this supposed to be available in some public repository? If yes where?
 
There could be also different kind of images. We could have, for example, images for simple data block devices. Are they supposed to be flagged by a different GUI?
 
===== '''VM Operator'''=====
 
In my opinion, if the VM Operator is responsible for the patching, vuln. management and logging capability of a VM, it can never be different from the Endorser. I can't see any reason to place those requirements on the head of the Operator when we are defining the figure of an Endorser who is responsible " that a particular VM image has been produced according to the requirements of this policy and states that the image can be trusted."
 
 
 
In fact those responsibilities are correctly defined in the '''Policy Requirements on the Endorser'''
 
==== Policy Requirements on the Endorser ====
 
===== '''Bullet 5-6''' =====
 
I still can't understand these two points. Do we require the VM images to be ''world readable'' or we are saying that the endorser should consider that the image can be inspected? If this is a requirement, why? and also who should be supposed to dig into them. What if some VM image contains some copyrighted software or some procedure that the VO wants to keep reserved? Why we should loose those potential use case as long as the image is not causing harm to the grid? Moreover, it is always possible to instantiate a VM which has this requirement and then read protect the filesystem after accessing it as administrator.
 
 
 
I already commented on bullet 6, this would exclude the possibility to have VM for services that require certificates.
 
 
 
= Old (HEPiX) policy text =
 
 
 
== Policy on the Endorsement of Virtual Machine Images ==
 
=== Introduction ===
 
This document describes the security-related policy requirements for the generation and endorsement of
 
trusted virtual machine (VM) images for use on the Grid.
 
 
 
The aim is to enable Grid Sites to trust and instantiate endorsed VM images that have been generated
 
elsewhere.
 
 
 
The virtualisation model addressed here is the use of virtual Grid worker nodes that act in a similar way
 
to real worker nodes. Virtualisation provides an efficient way of managing different configurations of
 
worker node, e.g. the operating system used, and importantly different pre-configured application
 
environments for the VOs. The model addressed here, therefore, simply provides a different way of
 
running authorized VO work, transparent to the end user, exactly the same as if the user payload was
 
running on a real worker node. There should be no need to place more restrictions on virtual worker
 
nodes running endorsed images as defined by this policy, than on real worker nodes in terms of access to
 
trusted local services at the site.
 
 
 
This policy does not compel Sites to instantiate images endorsed in accordance with this policy nor limit
 
the rights of a Site to decide to instantiate a VM image generated by any other non-compliant procedures,
 
should they so desire. The Site is still bound by all applicable Grid security policies and is required to
 
consider the security implications of such an action on other Grid participants.
 
 
 
=== Definitions ===
 
The following terms are defined.
 
* '''VM base image''': A VM image, including a complete operating system and all general
 
middleware, libraries, compilers, programmes and utilities. All kernel and root-level
 
configurations, including any that may be VO-specific, are included here.
 
* '''VO environment''': The VO-specific middleware, application software, libraries, utilities, data
 
and configuration which may be necessary to provide the appropriate environment for use by
 
members of a VO. No kernel modifications or root-level configurations are included here.
 
* '''VM complete image''': The VM image resulting from the combination of the VM base image and
 
the VO environment (if any).
 
* '''Globally Unique Identifier''': A unique identifier for a VM complete image.
 
* '''Endorser''': An individual who confirms that a particular VM complete image has been produced
 
according to the requirements of this policy and states that the image can be trusted.
 
 
 
=== Policy Requirements ===
 
An Endorser should be one of a limited number of authorised and trusted individuals appointed either by
 
a VO or a Site. The appointing VO or Site must assume responsibility for the actions of the Endorser and
 
must ensure that he/she is aware of the requirements of this policy.
 
==== Policy Requirements on the Endorser ====
 
By acting as an Endorser you agree to the conditions laid down in this document and other referenced
 
documents, which may be revised from time to time.
 
# You are held responsible by the Grid and by the Sites for checking and confirming that a VM complete image has been produced according to the requirements of this policy and that there is no known reason, security-related or otherwise, why it should not be trusted.
 
# You recognise that VM base images, VO environments and VM complete images, must be generated according to current best practice, the details of which may be documented elsewhere by the Grid.
 
#:These include but are not limited to:
 
* any image generation tool used must be fully patched and up to date;
 
* all operating system security patches must be applied to all images and be up to date;
 
* images are assumed to be world-readable and as such must not contain any confidential information;
 
* there should be no installed accounts, host/service certificates, ssh keys or user credentials of any form in an image;
 
* images must be configured such that they do not prevent Sites from meeting the finegrained monitoring and control requirements defined in the Grid Security Traceability and Logging policy to allow for security incident response;
 
* the image must not prevent Sites from implementing local authorisation and/or policy decisions, e.g. blocking the running of Grid work for a particular user.
 
# You must disclose to the Grid or to any Site on request the procedures and practices you use for checking and endorsing images.
 
# You must provide and maintain an up to date digitally signed list of your currently endorsed images together with the metadata relating to each VM image, as defined in the VM Image Catalogue document.
 
# You must keep an auditable history of every image endorsed including the Globally Unique Identifier, date/time of generation and full list of OS/packages/versions in both the VM Base Image and VO Environment. This must be made available to sites on demand.
 
# You must remove images from the approved list whenever a problem is found, e.g. a new security update is required. This removal must also be recorded locally in your auditable history.
 
# You are responsible for handling all problems related to the inclusion of any licensed software in a VM image. You shall ensure that any software included in a VM image which is used for its intended purposes, complies with applicable license conditions and you shall hold the Site running the image free and harmless from any liability with respect thereto.
 
# You must assist the Grid in security incident response and must have a security vulnerability assessment process in place.
 
# You recognise that the Grid, the Sites, and/or the VOs reserve the right to block any endorsed image or terminate any instance of a virtual machine and associated user workload for administrative, operational or security reasons.
 
# You recognise that if a Site runs an image which no longer appears on your list of endorsed images, that you are not responsible for any consequences of this beyond the time of your removal of the image from the list
 

Latest revision as of 17:08, 19 December 2012

Security Policy for the Endorsement and Operation of Virtual Machine Images

This draft policy is currently under external review. The text being reviewed may be seen at https://documents.egi.eu/public/ShowDocument?docid=771

As a result of the January 2011 SPG meeting, there was an item to work on a generalisation of the HEPiX Virtual Machines Endorsement Policy document.

The original HEPiX policy is available at https://edms.cern.ch/document/1080777

Introduction

This document describes the security-related policy requirements for the generation, distribution and operations of virtual machine (VM) images, as part of a trusted computing environment of the IT infrastructure.

The aim is to enable VM images to be generated according to best practices and to be both trusted and operated elsewhere.

This policy does not compel resource centres to instantiate images endorsed in accordance with this policy. Should a resource centre decide to instanciate a VM image generated by any other non-compliant procedures, that resource centre is still bound by all applicable security policies and is required to consider the security implications of such an action on other participants.

Definitions

The following terms are defined.

  • Endorser: A role, held either by an individual or a team, who is responsible for confirming that a particular VM image has been produced according to the requirements of this policy and states that the image can be trusted. An Endorser should be one of a limited number of authorised and trusted individuals appointed either by the infrastructure, a VO or a resource centre. The appointing body must assume responsibility for the actions of the Endorser and must ensure that he/she is aware of the requirements of this policy.
  • VM operator: A role, held either by an individual or a team, who is responsible for the security of the VM during its operation phase, from the time it is instantiated, until it is terminated. Typically this addresses individuals with root access on the VM.
  • Third party: An external entity other than the resource centre where the VM is operated.

Use case classification

The current policy document addresses the following use cases.

Endorser: resource centre, VM operator: resource centre

In this class virtualisation is not directly accessible by users. It includes, for example, the use of virtual worker nodes that act in a similar way to real worker nodes.

The resource centre is both the Endorser and the VM operator and is responsible to ensure the compliance of the VM with existing security policies.

Endorser: Third party, VM operator: resource centre

In this class, the resource centre is the VM operator, and the trust relationship is established between the resource centre and the Endorser.

Endorser: Third party, VM operator: Third Party

In this class, the resource centre runs the VM but is not the VM operator, and the trust relationship is established between:

  • the resource centre and the VM operator
  • the VM operator and the Endorser (both roles can be combined)

The resource centre is responsible to ensure sufficient traceability in order to enable malicious network activity to be linked with any VM and its VM operator, as defined in the Security Traceability and Logging policy.

The resource centre has no direct trust relationship with the Endorser and may decide to apply specific restrictions to control the access of the VM to other resources, including network services.

Policy Requirements on the VM Operator

By acting as a VM Operator you agree to the conditions laid down in this document and other referenced documents, which may be revised from time to time.

  1.  You are responsible to fulfil all the operational security and incident response requirements expressed in other policies
  2.  You are responsible to ensure that any VM being run is currently endorsed and to ensure its compliance with existing security policies, including but not limited to security patching, vulnerability management, incident response, logging and traceability.
  3. You are responsible for handling all problems related to the execution of any licensed software in a VM image. You shall ensure that any software run in a VM, complies with applicable license conditions and you shall hold the resource centre running the image free and harmless from any liability with respect thereto.
  4. You are responsible for contextualising any endorsed image, including credentials and certificates.

Policy Requirements on the Endorser

By acting as an Endorser you agree to the conditions laid down in this document and other referenced documents, which may be revised from time to time.

  1. You are held responsible by the infrastructure and by the resource centres for checking and confirming that a VM image has been produced according to the requirements of this policy and that there is no known reason, security-related or otherwise, why it should not be trusted.
  2. You recognise that the VM must be generated according to current best practice, the details of which may be documented elsewhere by the infrastructure. These include but are not limited to:
    1. any image generation tool used must be fully patched and up to date;
    2. all operating system and other installed software security patches must be applied to all images and be up to date;
    3. images are assumed to be world-readable and as such must not contain any confidential information;
    4. there should be no installed accounts, host/service private keys, ssh private keys or user credentials of any form in an image;
    5. images must be configured such that they do not prevent resource centres from meeting the finegrained monitoring and control requirements defined in the Security Traceability and Logging policy to allow for security incident response;
    6. the image must not prevent resource centres from implementing local authorisation and/or policy decisions, e.g. blocking the running of work for a particular user.
  3. You must disclose to the infrastructure or to any resource centre on request the procedures and practices you use for checking and endorsing images.
  4. You must provide and maintain an up to date list of your currently endorsed images together with the metadata relating to each VM image. The related guidelines will be made available by the infrastucture organisation.
  5. Either the list or each individual image's metadata must be digitally signed by the endorser.
  6. You must keep an auditable history of every image endorsed including the date/time of generation and full list, including exact versions, of installed software and operating system contained in the VM. This must be made available to resource centres on demand.
  7. You must implement a removal or revocation procedure to allow the VM operators to exclude those images which are no longer endorsed. This procedure must be implemented whenever a problem is found, e.g. a new security update is required. This removal must also be recorded locally in your auditable history.
  8. You are responsible for handling all issues related to the distribution of any licensed software in a VM image. You shall ensure that any software distributed in a VM image, complies with applicable license conditions and you shall hold the resource centre running the image free and harmless from any liability with respect thereto.
  9. You must assist the infrastructure in security incident response and must have a security vulnerability patching process in place.
  10. You recognise that the infrastructure, the resource centres, and/or the VOs reserve the right to block any endorsed image or terminate any instance of a virtual machine and associated user workload for administrative, operational or security reasons.
  11. You recognise that if a VM operator runs an image which is no longer endorsed, you are not responsible for any consequences of this beyond the time of your removal of the endorsement.