son-validate: authentication for accessing VDU image URL

[lconceicao]

In order to validate the existence of the VDU image in protected sites, son-validate must somehow access to authentication parameters. Currently there is not a mechanism that supports this.

One option would be to include the authentication parameters in the VNFD, however I do not find this solution secure nor convenient.

[jbonnet]

We could work on a solution with the users public/private keys?

[tsbatista]

I'm not sure how the authentication works between the SP component's, but that may not be an option, as the user's credentials will not be valid when querying the VIM for the existence of an image. Also, the user's private key should never be handed over to any component.

I would say this falls out of the scope of the current validator, as this functionality could not be used on a developer's laptop. However, if I were to implement it, I would introduce an optional configuration file with the credentials and endpoint for each VIM (do you have an internal abstraction for multi VIM scenarios? not sure about the sp internals, sorry).

What about implementing a server side validation tool? This tool could have knowledge of the internal topology of the SP, how many VIMs are there, and which ones should contain the image, an could perform more validations that depend on the specific SP configuration, such as what kind of images are supported, such as the case of an emulator based sp

[jbonnet]

Hi, @tsbatista

I'm not sure how the authentication works between the SP component's...

What do you need to know? :-) But this authentication (if I got it right) is not within the SP, it's between the SP and the 'place' where the image is stored... Am I right, @lconceicao or @DarioValocchi ?

...Also, the user's private key should never be handed over to any component.

Never said that. I've mentioned the private key in the context of using the usual pair private/public key to get the image. The SP has the developer's public key; can't we use it somehow? This wheel has for sure been invented before...

...this functionality could not be used on a developer's laptop

I totally agree. But we're reusing this component in the SP, so... the scope there might be valid, no?

...What about implementing a server side validation tool?...

Done, re-using the the SDK side tool, but for validating SONATA's packages. Here we're talking about validating VM images, namely if the SP can access them where the developer says they are. We've got a component on the pipeline, called Resolver/Image Store which will do some of those validations

[DarioValocchi]

Spending more than 1 second on the idea of having the credentials in the descriptor, I can't disagree with @lconceicao and @tsbatista. As I briefly mentioned to Luis on the gitter, this problem stretches out from the boundaries of the validator, and reaches also some elements in the SP, when it comes to fetching the VM image and provision it in the VIMs repositories. I think that the priv/pub key system could make sense. Since the VM image server is "locked" with the dev priv key, if the validator, or the GK are able to access it, they are shure the VM link has not been spoofed, and on his side, the developer has control in distributing its public key only to the people admitted to download that image.

[tsbatista]

@DarioValocchi

the developer has control in distributing its public key only to the people admitted to download that image.

Be very careful with this statement, you just turned your public key into a shared secret. Typically public keys can be public as by themselves they grant no privileges, they only grant privileges to the owner of the respective private key, the end user in this case. And we do not want the end user talking to any component beyond the gatekeeper directly

@jbonnet

We've got a component on the pipeline, called Resolver/Image Store which will do some of those validations

If so, should we duplicate the functionality in this tool? Or are you attempting to extend this tool to re-use it in that resolver?

[DarioValocchi]

@tsbatista

they only grant privileges to the owner of the respective private key, the end user in this case.

I disagree it grants no privilege, it grants the privilege to the GK that the image it is able to access/decript is indeed the one the developer meant to be used. But your are right, I agree that it grants no access limitation to such image, since the pub key is meant to be public.

[tsbatista]

True, when i said privilege I was thinking about executing any action on any SONATA API, a public key can and should be used to verify the integrity and provenance of signed data!