[glue-wg] New class and attributes for GLUE 2.1/cloud extensions

[Baptiste Grenier]

Hi Stephen,

Le 13/10/17 à 15:51, stephen.burke at stfc.ac.uk téléscripta :
>glue-wg [mailto:glue-wg-bounces at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1867 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/glue-wg/attachments/20171013/832b6f42/attachment.bin>