Here are the points that we will discuss about in this blog:
- What do we mean by Restricting Access
- Why is it needed
- Restricting access in LitmusChaos
- How we implemented it
What do we mean by Restricting Access
Access restriction, suggested by the name, refers to controlling the access level of a user for any resource as per their role in an organisation or project.
For example, a premium Spotify user will have access to download any song and play it offline, whereas a non-premium user cannot download the songs.
Why is it needed
Giving access to everything to everyone can be very vulnerable. Imagine google not restricting users to unmute other users, or Imagine the HR team having permissions to handle the Github repo of your project.
By implementing good restriction policies, it is possible for an organization to optimize the use of resources and build a better product.
Restricting access in LitmusChaos
LitmusChaos is a tool that allows users to test the resilience of their Kubernetes or non-Kubernetes applications when it is under testing in a chaotic environment.
LitmusChaos has built a cool teaming feature that enables users to have any of the three(Owner, Editor, Viewer) roles in a project.
The project owner has access to all the features in a project, right from inviting other members to their project, managing those members, scheduling workflows, and managing workflows.
The editor has the same privileges as the owner, minus managing the project and inviting other members to the project. The viewer has only access to view the workflows and analytics related to it.
You can read more about this feature here:
How we implemented it
The basic implementation that comes to mind is to disable the features that should not be accessed by the users in the user interface or just hide them. While it can be the first layer of security, it is not enough for a tool like litmus. Some users directly want to access the APIs, and therefore the validation has to be done while executing the API itself.
To ensure this here is the overview of architecture that we follow:
Before processing the request, the validator confirms if the user has sufficient permissions to access the resource. If not, then the request is not processed & instead, an error message will be presented to the user.
Conclusion
Thanks for sticking around. I hope you had a productive time reading this article.This article was also contributed by @vanshbhatiaa4k9
Are you an SRE or a Kubernetes enthusiast? Does Chaos Engineering excite you?
Join Our Community On Slack For Detailed Discussion, Feedback & Regular Updates On Chaos Engineering For Kubernetes: https://slack.litmuschaos.io (#litmus channel on the Kubernetes workspace)
LitmusChaos 2.0 GA will be out on 15th August 2021, with some exciting new features.
LitmusGithubRepo
Check out the Litmus Chaos GitHub repo and do share your feedback: https://github.com/litmuschaos/litmus
Submit a pull request if you identify any necessary changes.
Don't forget to share these resources with someone who you think might benefit from them. Peace out. ✌🏼
Top comments (0)