Plugin designed for handling provisioning
and deprovisioning of credentials for the WizCLI utility used to interact
with Wiz.
The WizCLI's auth subcommand takes a --id (56 character alphanumeric
string) and a --secret (64 character alphanumeric string) argument, or
alternatively looks for the WIZ_CLIENT_ID and WIZ_CLIENT_SECRET
environment variables, which it uses to request a time-limited access token
(Bearer token) from https://auth.app.wiz.io/oauth/token. The access token
is written to $WIZ_DIR/auth.json (defaults to $HOME/wiz/auth.json),
along with an expiration date, a data center identifier, tenant id and the
client id.
When a subcommand of the wizcli, that requires authentication (such as
wizcli iac scan --path . or wizcli dir scan --path .) is invoked, it
looks for the $WIZ_DIR/auth.json file for the access token to include.
This plugin implements the functionality of the auth subcommand and writes
the $WIZ_DIR/auth.json file in the expected format. After the wizcli has
completed, the $WIZ_DIR/auth.json file is deleted.
The plugin does not support importing, as the client secret is never written
to disk anywhere. Only access token (and a refresh token) is written, and
they will expire fairly quickly.
Note that the plugin doesn't invalidate the access token (or refresh token)
created, because Wiz doesn't seem to expose an API for that.
The plugin also requires the installation of the data center ID of ones Wiz
tenant and the tenant ID. This information can be found under
https://app.wiz.io/user/tenant. The information can alternatively be fetched
via the Wiz API, but this uses GraphQL and would introduce a new dependency
to this project.
Finally, the authentication could also be done by having the plugin invoke
the WizCLI's auth subcommand with the needed secret and client ID. Calling
the authentication API was chosen as an alternative because calling the
binary could be messy.
A future iteration of this plugin could choose to use the $WIZ_DIR
environment variable to point to a RAMdisk, to ensure the authentication
files are never written to persistent storage.
Unit tests not added as I was unsure what the preferred way of mocking upstream API calls is. Using the provisioning helper
test functions caused the test to reach out to the real API and there was no obvious way to add a mock.
Type of change
- [x] Created a new plugin
- [ ] Improved an existing plugin
- [ ] Fixed a bug in an existing plugin
- [ ] Improved contributor utilities or experience
## Related Issue(s)
* Resolves: #
* Relates: #
## How To Test
Overview
Plugin designed for handling provisioning and deprovisioning of credentials for the WizCLI utility used to interact with Wiz.
The WizCLI's
authsubcommand takes a--id(56 character alphanumeric string) and a--secret(64 character alphanumeric string) argument, or alternatively looks for theWIZ_CLIENT_IDandWIZ_CLIENT_SECRETenvironment variables, which it uses to request a time-limited access token (Bearer token) fromhttps://auth.app.wiz.io/oauth/token. The access token is written to$WIZ_DIR/auth.json(defaults to$HOME/wiz/auth.json), along with an expiration date, a data center identifier, tenant id and the client id.When a subcommand of the wizcli, that requires authentication (such as
wizcli iac scan --path .orwizcli dir scan --path .) is invoked, it looks for the$WIZ_DIR/auth.jsonfile for the access token to include.This plugin implements the functionality of the auth subcommand and writes the
$WIZ_DIR/auth.jsonfile in the expected format. After the wizcli has completed, the$WIZ_DIR/auth.jsonfile is deleted.The plugin does not support importing, as the client secret is never written to disk anywhere. Only access token (and a refresh token) is written, and they will expire fairly quickly.
Note that the plugin doesn't invalidate the access token (or refresh token) created, because Wiz doesn't seem to expose an API for that.
The plugin also requires the installation of the data center ID of ones Wiz tenant and the tenant ID. This information can be found under https://app.wiz.io/user/tenant. The information can alternatively be fetched via the Wiz API, but this uses GraphQL and would introduce a new dependency to this project.
Finally, the authentication could also be done by having the plugin invoke the WizCLI's
authsubcommand with the needed secret and client ID. Calling the authentication API was chosen as an alternative because calling the binary could be messy.A future iteration of this plugin could choose to use the $WIZ_DIR environment variable to point to a RAMdisk, to ensure the authentication files are never written to persistent storage.
Unit tests not added as I was unsure what the preferred way of mocking upstream API calls is. Using the provisioning helper test functions caused the test to reach out to the real API and there was no obvious way to add a mock.
Type of change
- [x] Created a new plugin - [ ] Improved an existing plugin - [ ] Fixed a bug in an existing plugin - [ ] Improved contributor utilities or experience ## Related Issue(s) * Resolves: # * Relates: # ## How To Testwizcli iac scan --path . --policy "Default secrets policy" wizcli iac scan --path . wizcli dir scan --path . --policy "Default secrets policy" wizcli dir scan --path .
Changelog
Authenticate the Wiz CLI using Touch ID and other unlock options with the 1Password Shell Plugins.