Throw error if yaml policy has unparseable attributes for Rule mode
What does this MR do?
Context:
A user can create policies in two ways: the Rule Mode and the YAML mode
| Mode | Details | Screenshot |
|---|---|---|
| Rule | allows users to create policies in a human-readable way |  |
| Yaml | allows users to create policies by filling out a yaml file |  |
We allow the users to switch back/forth between Rule Mode and Yaml Mode.
Problem:
The Rule Mode UI is ever evolving and will include many different types of policies to be created in the future, but currently it is limited and a user can do much more via Yaml Mode than Rule Mode. Additionally, with yaml being so much more configurable, we may never get to a point where the Rule Mode can do everything that one could do in Yaml mode.
What is the current behavior:
When a user switches from yaml mode to rule mode with properties that are not yet supported by Rule Mode, the fromYaml parser chops off the unsupported parts of the yaml.
What is the desired behavior
When a user switches from yaml mode to rule mode with properties that are not yet supported by Rule Mode, the fromYaml parser does not convert the yaml and the UI shows an informative alert that "Rules Mode" is not supported
Screenshots (strongly suggested)
| Policy Type | Rule Mode | Yaml Mode |
|---|---|---|
| Policy Editor - Unsupported Policy |  |
 |
| Policy Editor - Supported Policy |  |
 |
| Policy List - Unsupported Policy |  |
 |
| Policy List - Supported Policy |  |
 |
| Policy Editor - Unsupported yaml |  |
 |
| Policy Editor - Supported Policy |  |
 |
How to test
This is VERY complicated to test. You need the runner set up, you need kubernetes set up, you need cilium, etcetera. It is really a big deal, but here is the onboarding issue if you want to fare it. I am here to answer questions. Or we could zoom about it and you could inspect my local setup.
Does this MR meet the acceptance criteria?
Conformity
-
📋 Does this MR need a changelog?-
I have included a changelog entry. -
I have not included a changelog entry because _____.
-
-
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers -
Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec -
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team
Related to #271169 (closed)