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

FoD: Add functionality for 'refreshing' scan settings with new entitlement id #614

Open
rsenden opened this issue Sep 27, 2024 · 2 comments
Labels
effort:? enhancement New feature or request fcli-fod Issue related to 'fcli fod' commands prio:medium Medium priority

Comments

@rsenden
Copy link
Contributor

rsenden commented Sep 27, 2024

Enhancement Request

If the entitlement associated with an existing scan setup is deactivated (usually because it was replaced with a new entitlement), the fcli fod sast-scan start (and possibly the same for other scan types) will fail with an exception like the following:

image

Ideally, if possible, this should be fixed on the FoD side, with any existing scan setups automatically being reconfigured with the new entitlement id if an existing entitlement is replaced with a new entitlement.

Alternatively, we could implement the following functionality in fcli:

  • Get existing scan settings
  • Check whether entitlement id is still valid
  • If not, determine appropriate new entitlement id for the given scan settings
  • Update the scan settings with the new entitlement id, leaving all other scan settings the same

We could potentially implement this in 3 different places:

  • Add a --refresh-entitlement option on the existing sast-scan setup command, but this may be confusing, in particular in combination with the --skip-if-exists option.
  • Add a new refresh-entitlement, refresh-setup or update-setup command (the latter would allow for updating any scan settings while leaving all other scan settings the same)
  • Add this functionality to the sast-scan start command, controlled through a --[no-]refresh-entitlement option, not sure whether this should be enabled by default; enabling by default would be most convenient to automatically avoid exceptions like the above, but not sure whether there's any risk of selecting the wrong entitlement id
@rsenden rsenden added the enhancement New feature or request label Sep 27, 2024
@kadraman
Copy link
Collaborator

This logic is mostly already in fod xxx-scan setup via the ‎FoDScanHelper::getEntitlementToUse() method - which validates the entitlement is still valid. We could call this using existing scan configuration, e.g. Assessment Name/Type and try and find an appropriate entitlement but there is potential for a customer to have multiple current entitlements and there is no guarantee we would select the "right one". The entitlements are consumed at scan time so I can imagine if this is done automatically it could lead to lots of issues with wrong entitlements being consumed?

Maybe it would be better if the customer proactively had the ability to "migrate" the setup to using the correct entitlements. This would be best done using FoD UI itself, but maybe we can provide fcli commands to do this.

@rsenden
Copy link
Contributor Author

rsenden commented Sep 27, 2024

What about having an fcli update-entitlements action that takes old and new entitlement id's as input, then iterates through all existing scan setups and updates entitlementId if current scan setup entitlement id matches the given old entitlement id?

Although users would need to run this manually, and it would potentially take a long time to iterate through all existing scan setups, it would provide an easy way for users to migrate any existing scan setups to a new entitlement id.

@rsenden rsenden added fcli-fod Issue related to 'fcli fod' commands prio:medium Medium priority effort:? labels Sep 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort:? enhancement New feature or request fcli-fod Issue related to 'fcli fod' commands prio:medium Medium priority
Projects
None yet
Development

No branches or pull requests

2 participants