New class and attributes for GLUE 2.1/cloud extensions
Dear all, Please find here a proposition for the creation of a new clas and some attributes to replace the use of OtherInfo to represent some usefull cloud-related information. We would like to discuss this with you in order to integrate it in the GLUE2.1 draft as soon as possible. The names should be quite self explanatory, please let me know if you need any clarification. Best regards, Baptiste ## For CloudComputingEndpoint * GLUE2CloudComputingEndpointAuthentication * EndpointAuthentication_t * New type * Mandatory * Open enumeration * Default Values: X509-VOMS, OIDC ? * Replacing: * GLUE2EntityOtherInfo : Authn=X509-VOMS ## For CloudComputingImage * GLUE2CloudComputingImageDescription * New type * Mandatory * String * Replacing: * GLUE2EntityOtherInfo: description:Image for TinyCoreLinux * GLUE2CloudComputingImageVersion * New type * Mandatory * String * Replacing: * GLUE2EntityOtherInfo version:XXX * ContextualizationName_t * Existing type, just need to update default values * Open enumeration * Default Values: cloudinit (without a -), bash * Changing cloudinit to cloud-init (official name) * GLUE2CloudComputingImageNetworkInput / GLUE2CloudComputingImageNetworkOuput * Used to represent communication ports used/required/exposed by the image * Custom objectClass: NetworkTraffic * Optional * Can be specified multiple times * Replacing: * GLUE2EntityOtherInfo traffic-in:XXXXX * GLUE2EntityOtherInfo traffic-out:XXXXX * ObjectClass NetworkTraffic * New object class * inheriting from Entity * under/related to CloudCompoutingImage * Name * CloudCompoutingImageNetworkTraffic? * CloudCompoutingNetworkTraffic? * Attributes * NetworkTrafficProtocol_t: * Custom type * Mandatory * Closed enumeration * Values: all, tcp, udp, cmp, ipsec * NetworkTrafficType_t: * Custom type * Mandatory * Closed enumeration * Values: inbound, outbound * NetworkTrafficRange_t: * Custom type * Mandatory * String * Example (default?): 0.0.0.0/0 * NetworkTrafficPort_t: * Custom type * Mandatory * String * Example: 443 -- Baptiste Grenier EGI Foundation - Operations Officer Phone: +31 627 860 852 Skype: baptiste.grenier.egi
glue-wg [mailto:glue-wg-bounces@ogf.org] On Behalf Of Baptiste
Grenier said: The names should be quite self explanatory, please let me know if you need any clarification.
A few comments ...
* GLUE2CloudComputingEndpointAuthentication * EndpointAuthentication_t * New type * Mandatory * Open enumeration * Default Values: X509-VOMS, OIDC ? * Replacing: * GLUE2EntityOtherInfo : Authn=X509-VOMS
It's arguable that this should go into the base Endpoint definition as it's potentially useful for anything - although in that case it couldn't be mandatory as that would make all existing objects invalid. If it is mandatory you should probably have a NONE option or similar. Also is anything else needed? For the standard X509 case Endpoint has IssuerCA and TrustedCA, could other authn types need anything more? One other thing, X509-VOMS seems an odd value here since VOMS is about authorization (already covered by the Policy class) and not authentication.
* GLUE2CloudComputingImageDescription * New type * Mandatory * String * Replacing: * GLUE2EntityOtherInfo: description:Image for TinyCoreLinux
It seems slightly odd for a text description to be mandatory.
* GLUE2CloudComputingImageNetworkInput / GLUE2CloudComputingImageNetworkOuput * Used to represent communication ports used/required/exposed by the image * Custom objectClass: NetworkTraffic * Optional * Can be specified multiple times * Replacing: * GLUE2EntityOtherInfo traffic-in:XXXXX * GLUE2EntityOtherInfo traffic-out:XXXXX
This is missing a data type and a clear definition.
* NetworkTrafficProtocol_t: * Custom type * Mandatory * Closed enumeration * Values: all, tcp, udp, cmp, ipsec
Is that certain to be an exhaustive list?
* NetworkTrafficType_t: * Custom type * Mandatory * Closed enumeration * Values: inbound, outbound
TrafficDirection rather than Type? Never bidirectional?
* NetworkTrafficRange_t: * Custom type * Mandatory * String * Example (default?): 0.0.0.0/0
AddressRange rather than just Range?
* NetworkTrafficPort_t: * Custom type * Mandatory * String * Example: 443
Single valued or multivalued? Can it be a range or just a single port? If the latter why a string? Stephen
Hi Stephen, Le 13/10/17 à 15:51, stephen.burke@stfc.ac.uk téléscripta :
glue-wg [mailto:glue-wg-bounces@ogf.org] On Behalf Of Baptiste Grenier said:
A few comments ...
* GLUE2CloudComputingEndpointAuthentication * EndpointAuthentication_t * New type * Mandatory * Open enumeration * Default Values: X509-VOMS, OIDC ? * Replacing: * GLUE2EntityOtherInfo : Authn=X509-VOMS
It's arguable that this should go into the base Endpoint definition as it's potentially useful for anything - although in that case it couldn't be mandatory as that would make all existing objects invalid. If it is mandatory you should probably have a NONE option or similar. Also is anything else needed? For the standard X509 case Endpoint has IssuerCA and TrustedCA, could other authn types need anything more? One other thing, X509-VOMS seems an odd value here since VOMS is about authorization (already covered by the Policy class) and not authentication.
OK, so for the Mandatory flag I wasn't sure about the usage in the GLUE spec, I think this is an important information required to allow tools such as orchestrators to understand how they could (or couldn't) use an endpoint. But if its not possible/acceptable with regards to existing objects let's put it non mandatory. Or maybe can we put it as mandatory and have some kind of default value/option set to UNKNOWN? (we tend to prefer this to NONE as it is less ambiguous). What is the most appropriate? The X509-VOMS auth type is in fact something that is already published (probably not used yet) within EGI FedCloud, but yes its mixes authentication and authorization so having X509 and something for OIDC seems appropriate.
* GLUE2CloudComputingImageDescription * New type * Mandatory * String * Replacing: * GLUE2EntityOtherInfo: description:Image for TinyCoreLinux
It seems slightly odd for a text description to be mandatory.
Image description cannot be anything else than some free text, but yes we can certainly put it as optional, it shouldn't be a critical information.
* GLUE2CloudComputingImageNetworkInput / GLUE2CloudComputingImageNetworkOuput * Used to represent communication ports used/required/exposed by the image * Custom objectClass: NetworkTraffic * Optional * Can be specified multiple times * Replacing: * GLUE2EntityOtherInfo traffic-in:XXXXX * GLUE2EntityOtherInfo traffic-out:XXXXX
This is missing a data type and a clear definition.
In GLUE2CloudComputingImage we could have associations with GLUE2CloudComputingImageNetworkInput and GLUE2CloudComputingImageNetworkOuput. GLUE2CloudComputingImageNetworkOuput and GLUE2CloudComputingImageNetworkInput would be of the class NetworkTraffic, inheriting from Entity. Its attributes are presented below. We could have them multiple times as the goal is to be able to describe the list of required/expected input and output connections.
* NetworkTrafficProtocol_t: * Custom type * Mandatory * Closed enumeration * Values: all, tcp, udp, cmp, ipsec
Is that certain to be an exhaustive list?
Probably not, we can put it as an open enumeration with this list of values.
* NetworkTrafficType_t: * Custom type * Mandatory * Closed enumeration * Values: inbound, outbound
TrafficDirection rather than Type? Never bidirectional? TrafficDirection sounds good.
I'm not sure but I think we did not add bidirectional as the goal is to be able to know what are the ports to open in firewalls/security groups/... for inbound and outbound connections, and it is quite common to describe INPUT and OUTPUT separately. And as we have GLUE2CloudComputingImageNetworkInput (type would be always inbound) and GLUE2CloudComputingImageNetworkOuput (type would be always outbound) we should be able to describe everything and it will probably be easier to search with separate attributes. Does it make sense? If not what would do you think would be a more correct way to publish this info?
* NetworkTrafficRange_t: * Custom type * Mandatory * String * Example (default?): 0.0.0.0/0
AddressRange rather than just Range?
Sounds good too.
* NetworkTrafficPort_t: * Custom type * Mandatory * String * Example: 443
Single valued or multivalued? Can it be a range or just a single port? If the latter why a string?
We were thinking that it could be a port (53) range (0:1024) or a list (22,443), that's why it's a string. Thanks!
Stephen
Cheers, Baptiste -- Baptiste Grenier EGI Foundation - Operations Officer Phone: +31 627 860 852 Skype: baptiste.grenier.egi
Baptiste Grenier [mailto:baptiste.grenier@egi.eu] said:
But if its not possible/acceptable with regards to existing objects let's put it non mandatory. Or maybe can we put it as mandatory and have some kind of default value/option set to UNKNOWN? (we tend to prefer this to NONE as it is less ambiguous). What is the most appropriate?
Making a new attribute mandatory will always cause problems for backward compatibility because it says that an attribute must be present whereas existing info providers won't have it. At least in LDAP it's enforced at the server level, so if info providers don't publish mandatory attributes the whole object is rejected. In this case, at the moment we assume X509 authn so it's easy to continue to assume that if nothing different is specified. NONE would be different, you would use it for open services which don't require auth at all - in general that's always likely to be a possibility even if you wouldn't do it for particular services. An unknown value wouldn't make much sense here, anything using a service needs to know what kind of token it needs.
Probably not, we can put it as an open enumeration with this list of values.
That's likely to be better, normally closed enumerations are only for things which are logically complete.
Does it make sense? If not what would do you think would be a more correct way to publish this info?
I was just raising the question - if you say that something is a closed enumeration you aren't allowing a possibility for it to change in future, so you have to be sure that it's complete.
We were thinking that it could be a port (53) range (0:1024) or a list (22,443), that's why it's a string.
OK - but the definition should say explicitly what the allowed formats are. Stephen
Hi all, So going back to this, I started to update the draft so that we will have more concrete propositions to discuss and update and we can also add comments to the doc to help with the discussions. So I added Authentication in the base Endpoint and I added the EndpointAuthentication_t type as open enumeration with 3 values: none, x509 and oidc. Do you think that it would make sense to add something like Authorization in the same way? I added Description (0..1) in the CloudComputingImage. And in the same way, I added Version (0..1) in order to document the image version (not the OS image version). I added the NetworkTrafficProtocol_t type as open enumeration. I added the NetworkTrafficDirection_t type as open enumeration but I think that here we want to enforce usage of inbound or outbound (vs bidrirectional) to ease the search. I added the NetwrokTrafficAddressRange_t type, a string in CIDR format. I added the NetworkTrafficPort_t type as a string and specified the list of accepted formats (80 or 80,443 or 25000:25009) So I'm a bit unsure about how all those NetworkTraffic* attributes should be structured in a single object/type, at first I think we were planning to add a new NetworkTraffic_t type and use it for two new NetworkInput and NetworkOutput attributes but I'm not sure it is possible to have a structure made of custom types, so should we add a NetworkTraffic entity under something like the "Conceptual Model fo the Cloud Computing Service" and associate them to the image? Or should we define something else or somewhere else? One last point, sorry, I don't know at all what the hell happend but while I was adding some content the google doc crashed and asked me to reload. But due to missing content I add to restore a previous version from some minutes ago. And then I saw in the comments threads than some very old suggestions from Salvatore Pinto were shown as rejected by me (but I never did it), I tried to reload some previous version from the same day but the comments did not change, so I manually accepted them as they were looking all appropriate and I found better to have them accepted than rejected and hidden, you should be able to see them in the comments thread window. If you prefer someone can try to revert to a previous version before my edit and if it fixes the comment I can re-add the content I've been adding today (I've downloaded exports). Best, Baptiste -- Baptiste Grenier EGI Foundation - Operations Officer Phone: +31 627 860 852 Skype: baptiste.grenier.egi
Baptiste Grenier [mailto:baptiste.grenier@egi.eu] said:
Do you think that it would make sense to add something like Authorization in the same way?
Authz is via the Policy objects and the syntax can be fairly arbitrary, specified by the Scheme, so there probably shouldn't be a need to add anything.
So I'm a bit unsure about how all those NetworkTraffic* attributes should be structured in a single object/type, at first I think we were planning to add a new NetworkTraffic_t type and use it for two new NetworkInput and NetworkOutput attributes but I'm not sure it is possible to have a structure made of custom types, so should we add a NetworkTraffic entity under something like the "Conceptual Model fo the Cloud Computing Service" and associate them to the image? Or should we define something else or somewhere else?
I'm not sure what you want to achieve, can you be more specific? The schema itself doesn't really have types anyway beyond string and integer. The basic limitation is that you can't have tables in objects, if you have more than one multivalued attribute in an object you can't connect them together because the order they come in is undefined, so if you want a table each row has to be a separate object. Also of course a single object can only have a single set of associations. Stephen
Hi Stephen, The intent is to be able to document and publish information about the ports/protocol required for a particular VM to operate and expose its services. This would be useful for users and orchestrators to know what ports should be opened, especially on sites where everything is closed by default or only some selected ports are abailable. And it could also be interesting for security-related and other checks. So this information has to be collected at the image level and made discoverable. For EGI FedCloud we agreed on a way to document this and this new type is supposed to allow to express this. Thanks , Baptiste -- Baptiste Grenier EGI Foundation - Operations Officer Phone: +31 627 860 852 Skype: baptiste.grenier.egi
participants (2)
-
Baptiste Grenier -
stephen.burke＠stfc.ac.uk