Until now, I’ve only used the “None” provider. However, in connection with the MeshMap Alpha Program, the Meshery provider needs to be used, using either the GitHub or Twitter account. Now I wonder why exactly Meshery needs full access to either my Twitter or my GitHub account?
Copied from the Slack-thread:
@Michael Gfeller great question. I’ll have to refresh, but I don’t think that Twitter’s granularity of permissions met Meshery Cloud’s auth system requirements (needs user’s email address) without all of the rest of the permissions following along. None of those other permissions are used in anyway at all: only the account’s email address is kept on file and is what is used as the unique identifier of the account.
For GitHub, Meshery Cloud should probably allow users to wade into that level of permissions more gradually, however, it’s current behavior can be explained as such:
In the near future, Meshery GitOps is coming to a release near you (hopefully).
This is to say that Meshery will facilitate interaction with your repo(s) if you allow it to do so. Pattern management (and more broadly content management: filters, apps, patterns - - which is inclusive of service mesh configuration management) can be versioned.
MeshMap offers a fantastic (I think) way of understanding your service mesh deployments, their configuration, allowing you to be design and operate those deployments and their configurations with the blinders removed.
While this sort of visual and imperative way of configuring and operating your infra is extremely helpful to understanding what is going on and how your intended changes will take affect, we would be remiss not to facilitate Infra as Code principles with git-based integrations to your source code system(s) so that you can pipeline your changes; so that you can process your visually designed changes in the same way that you apply change management, CI/CD, approvals, and so on to the rest of your deployments.
In preparation for this, Meshery Cloud is set to request write permission to your repo(s) for purposes of auto generating a PR, for example.
For purposes of walking through your public repo(s) to conveniently find any K8s manifests that you might want to visualize and manage without having your Meshery deployment rate limiting for too many API calls to GH. (edited)
For purposes of walking through your private repo(s) to conveniently find any K8s manifests that you might want to visualize and manage. (edited)
Will Meshery Cloud v0.6.0 support all of the above? No. These permissions are being asked for in advance of the features coming forth.
Another considered feature is that of facilitating automatic migration of your services onto a service mesh - your services that already use conflicting microservice frameworks that, say already have retries enabled, for example, and that you want to transition responsibility to the service mesh to do. Meshery could analyze your repo(s) (your services) identifying commonly used client libraries, analyzing your use and then suggesting a service mesh configuration that will match your services’ current config.
…as an example of another potential use GH credentials to walk through a public or private repo.
Its worth looking over the Twitter developer app docs to see if there is more granular permissions that can be sought out. Meshery Cloud is simply looking for two things from LinkedIn, Twitter, and Google: an email address and a valid token.
In the case of GitHub, currently, Meshery Cloud is capable of taking things one step further (and we need to build docs/a UX around this that people are comfortable with) by walking through your repo, seeking out any existing pattern files that you might want to import.
It’s a great question, @Michael Gfeller and completely warranted. I’m hoping this 1) clarifies and 2) is satisfactory, because it not, we need to 3) make #1 and #2 so.
Also, either (or both) of your LinkedIn or Google accounts can participate in the program as well. I suspect, but can’t quite recall at the moment, that those might be less intrusive. Any which of the four or all four will work. (edited)
I spoke to this in context of patterns and MeshMap, but historically Meshery (from its genesis) has needed a way of achieving one of its goals: analyzing and answering questions on the performance of service meshes. In order to do so, Meshery has needed a mechanism to securely collect performance tests for those users that share the test results (a user preference setting). Use of Meshery Cloud in this way serves for purposes of that research (ongoing in SMP) and for purposes of users conveniently recalling their prior performance test results as they can be retrieved when the user signs back in under the same account.
Thank you @Lee for the detailed and clarifying answer!
The (future) GitOps based integration and interaction with one’s repositories in GH makes completely sense. I wish GH would support more fine-grained access control to (private) repositories, though, for apps (or does it?).
In absence of that, I think I would prefer separate accounts for integrations like this… obviously this has disadvantages as well.
I’m not sure I understand the security related implications of such integrations, for instance the risk and consequences of the app requesting access being compromised. It would also be nice to be informed whether and how access can be revoked, and information exchanged be deleted before pressing the button (and having to dig around in documentation to find out).
These are excellent follow up considerations and concerns: data privacy, system security, liability (exposure and risk).
On data privacy, a new feature request filed on Meshery Cloud has been filed (#111). Details:
Current Behavior
On the Meshery Cloud sign-in page (screenshot below),
Add a similar sentence with hyperlink like that of what is seen on the provider-ui:
Desired Behavior
Question: “What happens when I authenticate?”
Question: “What data does Meshery Cloud collect? How does Meshery Cloud use my data?”
Instructions on
Implementation
-
Show a modal containing these two questions and their answers, similar to the existing modal on the
provider-ui:
-
Include instructions and a screenshot of user preferences (see example).
Meshery Cloud’s existing privacy policy and terms of service are quite generic in description (and inconveniently lengthy).
@Michael,to your point, it seems that additional GDPR-related Q&A would be enlightening (and hopefully, comforting) like: Is my data encrypted? How can I request a copy of my data? How can I request to have my data expunged (my account deleted)?
Your input here is much appreciated, @Michael. I suspect straight-forward and other Q&A relevant to the permissions requested like: “Will Meshery Cloud ever tweet on my behalf?” would be helpful as well.
1 Like
@Lee yes to all of that, thank you. I’m convinced that this will increase the trust-level in Meshery.
Yes, GDPR and Schrems II (my knowledge about those is general-public one).
Is Meshery cloud a private repository, and is the provider code there?
Personally, I’ve become extremely skeptical in recent past with all these integrations between apps, where it is almost impossible to have overview over how personal data flows between them. This has nothing to do with Meshery per se.
1 Like
