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.

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

Integration of Witness Policy Tool into Witness with New Command witness policy #344

Open
colek42 opened this issue Jan 2, 2024 · 6 comments

Comments

@colek42
Copy link
Member

colek42 commented Jan 2, 2024

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
Copy link
Member Author

colek42 commented Jan 2, 2024

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
Copy link

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
Copy link
Member Author

colek42 commented Jan 3, 2024

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
Copy link
Contributor

matglas commented Jan 4, 2024

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
Copy link
Collaborator

+1 for Approach Mapping Flags to Steps

@colek42
Copy link
Member Author

colek42 commented Jan 15, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants