Integration of Witness Policy Tool into Witness with New Command `witness policy`

[colek42]

Introduction:

Proposing the integration of the Witness Policy Tool into Witness, including the addition of a new command: witness policy. This integration aims to streamline processes and improve usability.

Proposal for Integration and New Command:

Integrating the Witness Policy Tool's features directly into Witness with a new command witness policy for a cohesive experience.

Features for Integration with witness policy Command:

• Policy Creation and Validation: Capability within witness policy to create and validate policy files.
• Rego Module Generation: Inclusion of Rego module generation for attestation validation in the witness policy command.
• Complex Policy Support: Handling sticky values, custom Rego modules, and certificate constraints through witness policy.

Command Integration and Usage:

• Integrate Witness Policy Tool’s commands into Witness under witness policy, ensuring seamless command syntax and functionality.

Advanced Features:

• Focus on custom Rego modules, certificate constraints, and diverse attestation data types under the witness policy umbrella.

Benefits:

• Streamlined Workflow: A unified command enhances user experience and efficiency.
• Enhanced Functionality: Expands Witness’s capabilities for SDLC security management.
• Increased Adoption: A more intuitive and powerful tool fosters wider usage.

Conclusion:

The integration of the Witness Policy Tool into Witness, crowned by the witness policy command, will create a comprehensive and user-friendly solution for managing SDLC security and integrity.

ref github.com/testifysec/

[colek42]

We need a way to map flags to steps, there are two approaches I am considering:

Approach 1: Mapping Flags to Steps

In this approach, users explicitly map each flag to a step using a key-value pair. It requires users to be explicit about which step each flag applies to.

Command Example:

witness policy generate --step "build" --step "deploy" --root-ca "build=rootCA.pem" --root-ca "deploy=deployCA.pem" --public-key "build=buildKey.pub" --public-key "deploy=deployKey.pub"

Here, the user specifies each flag with a corresponding step name (build or deploy) and the appropriate file.

Approach 2: Ordering-Based Flag Association

In this approach, flags are assumed to apply to the most recently defined step, based on their order in the command. Users list flags immediately after the step to which they apply.

Command Example:

witness policy generate --step "build" --root-ca "rootCA.pem" --public-key "buildKey.pub" --step "deploy" --root-ca "deployCA.pem" --public-key "deployKey.pub"

In this example, the root-ca and public-key flags are applied to the nearest preceding --step flag. This approach is more intuitive for users as it follows the natural flow of command-line input.

User Experience Consideration:

• Mapping Approach: More explicit, suitable for complex configurations, but can be verbose.
• Ordering Approach: More intuitive and streamlined, easier for simple to moderately complex setups.

[cortesnoel-lm]

One vote for the mapping approach. Generally prefer the UX of unordered cli flags and it'll retain flexibility of potential future cli flag placement for new features. Maybe can also be paired with an assumption that if only one step is given, then step-specifiers for associated flags not needed.

[colek42]

This is what im thinking right now. Agree that mapping, though more verbose, is a more explicit approach. I think we could also define multiple or all steps for a parameter.

ex:

multiple steps

--sticky deploy=sticky.yml --sticky deploy,test,build=sticky.yml --sticky *=sticky.yml

single step

--sticky sticky.yml

[matglas]

Upvote on the mapping. If that support unordered flags its much less prone to making mistakes. Ordered flags are much more prone for me to make mistakes. And less easy to adapt scripts while working on it. So from a UX perspective, although more explicit, it more flexible in use in my opinion.

[kairoaraujo]

+1 for Approach Mapping Flags to Steps

[colek42]

I am going to start by adding a witness policy check command, there is a draft PR up