-
Notifications
You must be signed in to change notification settings - Fork 683
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.
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
Initial control isolation support #973
Conversation
255ab53
to
bbe878b
Compare
bbe878b
to
91630ab
Compare
91630ab
to
f65c36f
Compare
Partially fixes #958 by ensuring that the profile context that we load during include_control and require control uses the dependencies for the given profile, not for the parent profiles. |
19c51bc
to
71c8dcb
Compare
bc26eb9
to
4c5f277
Compare
def all_rules | ||
ret = @rules.values | ||
ret += @subcontexts.map(&:all_rules).flatten | ||
ret |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah nice :-)
4c5f277
to
bbc6bc5
Compare
This is a great improvement @stevendanna Thanks 💯 |
The goal of this change is to provide an isolated view of the available profiles when the user calls the include_controls or require_controls APIs. Namely, - A profile should only be able to reference profiles that are part of its transitive dependency tree. That is, if the dependency tree for a profile looks like the following: A |- B --> C | |- D --> E Then profile B should only be able to see profile C and fail if it tries to reference A, D, or E. - The same profile should be include-able at different versions from different parts of the tree without conflict. That is, if the dependency tree for a profile looks like the following: A |- B --> C@1.0 | |- D --> C@2.0 Then profile B should see the 1.0 version of C and profile D should see the 2.0 profile C with respect to the included controls. To achieve these goals we: - Ensure that we construct ProfileContext objects with respect to the correct dependencies in Inspec::DSL. - Provide a method of accessing all transitively defined rules on a ProfileContext without pushing all of the rules onto the same global namespace. This does not yet handle attributes or libraries.
bbc6bc5
to
64a5a4d
Compare
There is a known issue https://github.com/chef-cookbooks/compat_resource, therefore we ignore the errors in our kitchen tests |
related to #888 |
The goal of this change is to provide an isolated view of the available
profiles when the user calls the include_controls or require_controls
APIs. Namely,
A profile should only be able to reference profiles that are part of
its transitive dependency tree. That is, if the dependency tree for a
profile looks like the following:
A
|- B --> C
|
|- D --> E
Then profile B should only be able to see profile C and fail if it
tries to reference A, D, or E.
The same profile should be include-able at different versions from
different parts of the tree without conflict. That is, if the
dependency tree for a profile looks like the following:
A
|- B --> C@1.0
|
|- D --> C@2.0
Then profile B should see the 1.0 version of C and profile D should
see the 2.0 profile C with respect to the included controls.
To achieve these goals we:
correct dependencies in Inspec::DSL.
ProfileContext without pushing all of the rules onto the same global
namespace.
This does not yet handle attributes or libraries.