[RFE] Norman to Webhook - Auth configs

Migration Checklist

Items 6-8 are post-feature-complete

• 1. Duplicate Norman Validation and Mutation - link
• 2. Review and Migrate Norman Actions - link
• 3. Security checks - link
• 4. Document CRDs in Rancher - link
• 5. Expose CRUD operations in Steve - link ---post-feature-complete---
• 6. Validate Fleet Use Cases - link
• 7. Document workflows - link
• 8. Review if you can deprecate CLI commands

1. Duplicate Norman Validation and Mutation

Currently, Norman performs significant validation and mutation of CRDs, which should be done exclusively through the webhook. These mutations/validations should be documented (as appropriate, likely inside the webhook). Validation in the webhook which provides security functionality should use a "failPolicy" of "Fail", which will prevent users from bypassing security validations when the webhook is unavailable. Validations/mutations can be found in the following locations:

Validation can be found via:

• Validators
• Store Handler. This can be in multiple places.
• Norman Struct Tags - there are several tags here to be aware of.

Mutations that Norman performs for CRDs should be moved to a controller or a webhook. Mutations can be found in store handlers

Action Items

• Test that a user can not bypass Norman Validation or Mutations by creating and updating an object via kubectl.
• List all validations as a comment in the issue, see example. In some cases this is infeasible due to complexity, adjust as necessary.

2. Review and Migrate Norman Actions

Review the actions exposed by Norman for this resource. In a comment on issue, provide the following:

• A list of all actions for this resource (or a confirmation that there is none)
• The migration strategy for each action
• A brief reasoning for the migration strategy that was chosen

For each migration strategy which requires a change, make those changes at this point.

3. Security Checks

Please answer the following questions in a comment on this issue

• Who should have access to the CRD, thinking about Rancher's default provided roles: admin, standard user, base user?
  • Or would you consider that a new role might benefit from this CRD?
  • restricted-admin must not be considered, because it will be deprecated.
• Are there non-standard RBAC rules which are used to access this resource (e.g., for clusters can I update the cluster if I have update on clusters or do I need some special verb)?
• Is there any other resource that you need to have access on to use this resource (e.g., it can be challenging to use clusters without having access to cloud credentials)?
• Do any permissions on this resource grant permissions to other resources (e.g. if I have write on users I may be able to create a new user for myself and/or change the password of other users)?
• What validation do you need for this type?
  • Where is this validation (webhook/controllers)?
  • Is the validation local-only or also present in downstream clusters?
  • For webhook-based validation you can link to the docs completed as part of the other steps.
• Open a new issue in the rancher/security-team repo, with assessment template (delete whats not relevant). Include link back to this comment to review.

Critical Security issues found during this phase should be addressed now, before public release of the CVE. Examples of such issues include: sensitive data, passwords, tokens, keys etc. stored in plaintext (config maps) must be migrated to secrets. Some existing issues may be resolved later, if further work on the public API does not make the issue worse, and if Engineering and Security both agree to move it out (due to scope creep), but a clear timeline must be provided at this stage.

4. Document CRDs in Rancher

Add code documentation to our CRDs structs in pkg/apis, including comments on each field with any necessary validation information. This is the actual "public-api" portion.

To meet the requirements of HLR3, each CRD that is migrated will need to follow the process defined in Document Rancher CRDs, and all fields will need to be documented for customer use. In addition, all validations/mutations should be documented using the Webhook's Documentation Strategy.

5. Expose CRUD operations in Steve

Steve currently prevents users from creating/deleting resources in the managment.cattle.io and project.cattle.io groups due to safety concerns. After the validation has been duplicated in the webhook, allow access to the Steve endpoints /v1 for the CRD so a user can perform Get, List, Create, Update, and Delete operations. This can be done by adding the CRD to the allow all list in disallow.go. If the CRD is not apart of managment.cattle.io or project.cattle.io group no action should be required for this step.

Note that the above prohibitions on Steve still apply - users will still not be expected/supported in any operations using Steve. This is done so that the UI can easily edit objects retrieved through Steve (which has enhanced performance).

Testing Expose CRUD operations in Steve

Verify that an admin can Get, List, Create, Update, and Delete via Steve for the migrated CRD.

6. Validate Fleet Use Cases

Given SURE-6539 is a P1, a manual test (done either by dev or QA) should be performed to ensure that fleet works with the migrated CRD. This test does not need to be exhaustive and should just confirm basic functionality.

Where appropriate, a basic end-to-end automated test case should be created which ensures that this resource can be created (and function correctly) using fleet. While this is not strictly necessary for the initial implementation, the possibility of creating this test case should be investigated, and if one is not created, a reasoning should be described on issue as to why the test was not made.

7. Document important workflows

We want each CRD to have at minimum 1 workflow doc, meaning a general example use-case. This does not need to be done at feature-complete, but should be done before release, so feel free to spin this into a separate issue. For each flow, make a sub-task on SURE-6544, and provide the docs team with CRD files that would need to be applied, and rough guidelines on how to apply them. The docs team will be responsible for writing up each flow in a common format.