Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

API Data and Framework Versioning. #1622

Merged
merged 7 commits into from
Jan 28, 2023
Merged

API Data and Framework Versioning. #1622

merged 7 commits into from
Jan 28, 2023

Commits on Jan 27, 2023

  1. API Data and Framework Versioning. 

    This change adds several features that are necessary to provide stable backwards
compatibility.

The first deals with how API defaults are specified.
Previously, API default behavior was given in terms of allow/deny, i.e.

``` rego
"create_container": {"introducedVersion": "0.1.0",
                     "allowedByDefault": false}
```

This does not reflect how the API has evolved, in particular the fact that GCS
expects the API to return objects and not a single boolean value. Thus, the
defaults have been updated to be default object values:

``` rego
"create_container": {"introducedVersion": "0.1.0",
                     "default_results": {"allowed": false,
                                         "env_list": null,
                                         "allow_stdio_access": true}},
```

The resulting default object is then combined with the value returned by the
(older) policy using an object union operation. For example, if the
default is:

``` json
{
    "allowed": false,
    "env_list": null,
    "allow_stdio_access": true
}
```

and the value returned by an older policy is:

``` json
{
    "allowed": true,
}
```

then then the fields of the policy result overwrite the fields of the default
to create the final result:

``` json
{
    "allowed": true,
    "env_list": null,
    "allow_stdio_access": true
}
```

As the API stabilizes, it will increasingly be the case that the Framework will
change independently of the API and will need its own SVN. The second major
change this PR incorporates is to add a Framework SVN to fragments and policies
which use the provided framework. This allows us to provide Framework-specific
backwards compatibility behavior. In particular, this allows us to specify
policy object versioning via the new `framework_objects.json` file. For example,
the format of the external process object is defined as:

``` json
"external_process": {
    "command": {
        "introduced_version": "0.1.0",
        "default_value": null
    },
    "env_rules": {
        "introduced_version": "0.1.0",
        "default_value": null
    },
    "working_dir": {
        "introduced_version": "0.1.0",
        "default_value": null
    },
    "allow_stdio_access": {
        "introduced_version": "0.1.0",
        "default_value": null
    }
},
```

As new elements are added to framework policy objects, reasonable defaults can
be provided here. This has repercussions on policies in a few cases:

1. **`framework_svn` is missing.** If the policy or fragment does not define a
   Framework SVN, then the framework must thrown an error for any rule which
   uses the object defaults, as the behavior is undefined.
2. **`framework_svn` is ahead of the executing Framework SVN**. Similarly, if
   a policy or fragment specifies an SVN which is greater than that of the
   executing Framework, they are indicating that they expect a different set of
   constraints to be executing and thus we must thrown an error when rules
   that uses object defaults are executed.

Implementing and testing these changes required some minor alterations and
refactoring to the `regopolicyinterpreter`, in particular a method to make
raw Rego queries to facilitate testing the default application process for
candidate policy objects.

Signed-off-by: Matthew A Johnson <[email protected]>
    @matajoh
    matajoh committed Jan 27, 2023
    Configuration menu
    Copy the full SHA
    83e0a48 View commit details
    Browse the repository at this point in the history

  2. Addressing PR comments 

    Signed-off-by: Matthew A Johnson <[email protected]>
    @matajoh
    matajoh committed Jan 27, 2023
    Configuration menu
    Copy the full SHA
    a058c00 View commit details
    Browse the repository at this point in the history

  3. Fixing a bug in the simulator 

    Signed-off-by: Matthew A Johnson <[email protected]>
    @matajoh
    matajoh committed Jan 27, 2023
    Configuration menu
    Copy the full SHA
    cf5acc8 View commit details
    Browse the repository at this point in the history

  4. Small change to defaults behavior 

    Signed-off-by: Matthew A Johnson <[email protected]>
    @matajoh
    matajoh committed Jan 27, 2023
    Configuration menu
    Copy the full SHA
    80d9561 View commit details
    Browse the repository at this point in the history

  5. Adding default behavior for arrays of sub-objects. 

    Signed-off-by: Matthew A Johnson <[email protected]>
    @matajoh
    matajoh committed Jan 27, 2023
    Configuration menu
    Copy the full SHA
    2515c9f View commit details
    Browse the repository at this point in the history

  6. Fixing bug with env_list default 

    Signed-off-by: Matthew A Johnson <[email protected]>
    @matajoh
    matajoh committed Jan 27, 2023
    Configuration menu
    Copy the full SHA
    de7a2a6 View commit details
    Browse the repository at this point in the history

  7. Moving SVNs to files 

    Signed-off-by: Matthew A Johnson <[email protected]>
    @matajoh
    matajoh committed Jan 27, 2023
    Configuration menu
    Copy the full SHA
    881848f View commit details
    Browse the repository at this point in the history