Follow-up from "Add Gitlab::Serverless::FunctionURI class"
The following discussion from !22733 (merged) should be addressed:
-
@ayufan started a discussion: (+4 comments) This misses authorization of whether we can access given environment in a given processing context.
This can lead to potential disclosure of data, as we accept external data, that are easily guessable, like
ID
(id is a sequential number). Someone, could try to use incremental numbers to disclose the objects.It is at least expected, that we do not perform system-wide search, but rather a search within a given context, like a context of serverless domain cluster.
@ayufan The context here is generally speaking going to be global, since we are going to be fielding a request from Pages daemon in response to an unauthenticated request to Pages, and we have no idea what group, project, etc. is involved at this point in the code. If we were to try and traverse up through
Serverless::DomainCluster
we would not be able to find a group or project scope, since clusters can be instance level, group level, or project level, and there is no direct relationship to traverse.Environment
as provided in combination with cluster is how we find the kubernetes namespace, which will fail unless the project related to the environment has deployed functions into the cluster, and I am also checking theslug
to make sure it matches to prevent enumeration, which I think eliminates the concern around disclosure of data, and otherwise it's rather a chicken and egg situation, unless you have any other ideas.