human-readable test fixtures

[djellemah]

Prepare

• Read PR guidelines
• Read license information

---

Description

There are two main goals this PR aims to achieve:

1. Extend the policy-store_xxx.json to allow for metadata for cedar_schema and policy_content fields.

2. Provide a proof of concept for a 100% human-readable test fixture, in yaml.

Target issue

#9961

Implementation Details

1. In policy-store_xxx.json files, allow for cedar_schema and policy_content fields to store human-readable values, rather than only the base64-encoded values that agama lab produces. To achieve this, the policy-store_xxx.json json for cedar_schema and policy_content is extended slightly with the following:

"policy_content": {
    "encoding": "none",
    "content_type": "cedar",
    "body": "permit(...) when { ... };"
}

• encoding can be one of none or base64

• content_type can be one of cedar or cedar-json for cedar_schema, but only cedar for policy_content

• body must contain a value that conforms with the above two.

Where the value for cedar_schema and policy_content is a plain string, it is assumed that the current convention is used:

• for cedar_schema, the value is base64 encoded, and contains the cedar-json representation of a schema

• for policy_content, the value is base64 encoded, and contains the cedar representation of a policy

2. This is a proof-of-concept, and intended for test fixtures only. Since serde is deisnged to deserialize from several formats, and since serde_yml exists, and since json is a proper subset of yaml, the last commit contains a 100% human readable test fixture containing cedar embedded in yaml.

---

Test and Document the changes

• Static code analysis has been run locally and issues have been fixed
• Relevant unit and integration tests have been added/updated

NOTE that docs will be updated once it's been agreed that the above code changes make sense.

• Relevant documentation has been updated if any (i.e. user guides, installation and configuration guides, technical design docs etc)

Please check the below before submitting your PR. The PR will not be merged if there are no commits that start with docs: to indicate documentation changes or if the below checklist is not selected.

• I confirm that there is no impact on the docs due to the code changes in this PR.

Closes #10007,

[dryrunsecurity]

DryRun Security Summary

The pull request introduces several improvements to the Cedarling application's security and robustness, particularly in the areas of policy and schema management, including enhanced policy and schema handling, improved extensibility and maintainability, secure policy and schema definitions, and reasonable dependency management.

Expand for full summary

Summary:

The code changes in this pull request introduce several improvements to the Cedarling application's security and robustness, particularly in the areas of policy and schema management. The key changes include:

1. Improved Policy and Schema Handling: The introduction of the Encoding and ContentType enums, as well as the EncodedPolicy and MaybeEncoded structures, allows the application to handle policy and schema metadata in a more flexible and secure manner. This reduces the reliance on external dependencies, such as the base64 crate, and improves error handling during deserialization.

2. Extensibility and Maintainability: The changes demonstrate a focus on designing the application with future extensibility in mind. The introduction of the CedarSchema struct and the support for both plain and encoded policy content indicate a thoughtful approach to accommodating potential changes, such as the addition of Cedar JSON policies, without major refactoring.

3. Secure Policy and Schema Definitions: The new policy and schema definitions, provided in the test files, showcase the use of the CEDAR policy language and a structured schema. These definitions follow the principle of least privilege and include appropriate conditional logic, which is a positive security practice.

4. Dependency Management: The update to the Cargo.toml file to include the serde_yml dependency is a reasonable change, as it allows the application to handle YAML-formatted data. While it's important to monitor the security of dependencies, the version of serde_yml used does not appear to have any known critical vulnerabilities.

Overall, the changes in this pull request demonstrate a thoughtful and secure approach to the Cedarling application's policy and schema management, with a focus on improving flexibility, robustness, and maintainability. As an application security engineer, I would recommend approving these changes, while continuing to monitor the project's dependencies and regularly review the security of the application's core functionality.

Files Changed:

1. jans-cedarling/cedarling/src/common/mod.rs: Introduces new Encoding and ContentType enums to handle policy and schema metadata.
2. jans-cedarling/cedarling/Cargo.toml: Adds the serde_yml dependency for YAML serialization and deserialization.
3. jans-cedarling/cedarling/src/common/policy_store.rs: Removes the base64 dependency and introduces new structures to handle policy content and encoding.
4. jans-cedarling/cedarling/src/common/cedar_schema.rs: Improves the deserialization and equality comparison of CedarSchema instances.
5. jans-cedarling/test_files/policy-store_blobby.json: Adds new policy definitions in the CEDAR policy language.
6. jans-cedarling/test_files/policy-store_readable.yaml: Adds new policy and schema definitions in a more human-readable YAML format.
7. jans-cedarling/test_files/policy-store_readable.json: Adds new policy and schema definitions in a JSON format.

Code Analysis

We ran 9 analyzers against 7 files and 0 analyzers had findings. 9 analyzers had no findings.

Riskiness

🟢 Risk threshold not exceeded.

View PR in the DryRun Dashboard.

[mo-auto]

Error: Hi @djellemah, You did not reference an open issue in your PR. I attempted to create an issue for you.
Please update that issues' title and body and make sure I correctly referenced it in the above PRs body.

[olehbozhok]

Looks OK to me

[rmarinn]

looks good to me but i'm curious why you chose YAML over TOML since Cargo prefers using TOML. But honestly, i think it doesn't matter too much in the end 😅

[djellemah]

looks good to me but i'm curious why you chose YAML over TOML since Cargo prefers using TOML. But honestly, i think it doesn't matter too much in the end 😅

Well, two things really:

1. YAML has excellent support for embedded, indented, multiline values. Which is exactly what we need for cedar.

2. It supports anything that serde does, so my guess is supporting TOML would be almost trivial. Does TOML support multiline strings? I've never really used it outside the context of config files. Oh, by multiline string, I mean something nicer than the way JSON can support multiline strings with embedded \n characters.