Closed kkotula closed 2 years ago
The title of this Pull Request needs to be changed to match the format:
<type>(<scope>): <subject>
See more details here: https://www.spinnaker.io/community/contributing/submitting/#commit-message-conventions
Some common examples are:
feat(armory.io): add docs.armory.io
fix(parser): grammar and spelling
style(loadingPage): made it super pretty!
refactor(helpMessages): changed order to make more sense
The title of this Pull Request needs to be changed to match the format:
<type>(<scope>): <subject>
See more details here: https://www.spinnaker.io/community/contributing/submitting/#commit-message-conventions
Some common examples are:
feat(armory.io): add docs.armory.io
fix(parser): grammar and spelling
style(loadingPage): made it super pretty!
refactor(helpMessages): changed order to make more sense
In this PR I try to address lack of permissions validation in dinghy.
The problem: Each application may have a set of user's roles required to either WRITE or READ or EXECUTE or variation of all of the above. It is possible that user X cannot modify an application using deck due to missing write permission, however nothing prevents the user of changing application's permissions in dinghyfile and pushing that to a repository. In such case application level permissions will be overridden with values from dinghyfile. It is considered by many of our clients as a security issue.
The solution: The solution is fairly simple - before updating application's attributes, we need to ask Fiat about user X's roles and compare them with application's permissions. If user has write access, they can change application's attributes. If they don't, an error is returned. New feature is not enabled by default. To enable it, clients need to set flag
userWritePermissionsCheckEnabled
to true.