13eeebe548
Changes: - Created a new database model: `MicrosoftComplianceTenant`. A model that stores information about complaince tenants - Added `/policies/is-cloud-customer`: a policy that blocks requests to microsoft proxy endpoints if a `MS API KEY` header is missing or does not match a new config variable (`sails.custom.config.cloudCustomerCompliancePartnerSharedSecret`) - Added `microsoft-proxy/create-compliance-partner-tenant`: an action that creates a database record for a new compliance tenant and generates an API key that is used to authenticate future requests to microsoft proxy endpoints for an entra tenant. - Added `microsoft-proxy/get-compliance-partner-settings`: an action that returns information about Fleet's complaince partner entra application and the entra tenant's admin consent status (whether or not a tenant's entra admin has granted permissions to Fleet's compliance partner application) - Added `microsoft-proxy/get-tenants-admin-consent-status`: an action that updates the admin consent status of a compliance tenant record. - Added `microsoft-proxy/setup-compliance-partner-tenant`: an action that provisions a compliance tenant, creates a complaince policy for macOS devices assigns the created policy to the built-in "All users" user group on the tenants entra instance. - Added `microsoft-proxy/update-one-devices-compliance-status`: an action that receives information about a device on a compliance tenant's Fleet instance, sends that information to their Entra instance, and returns the messsage ID returned by the asynchronus Entra API. - Added `microsoft-proxy/get-one-compliance-status-result`: an action that returns the result of a compliance status update from the Entra API. - Added `sails.helpers.microsoft-proxy.get-access-token-and-api-urls` A helper that gets an access token for a tenant's entra instance and the URLs of the API endpoints the microsoft proxy actions use for a tenant. - Added `scripts/send-entra-heartbeat-requests` A script that will run daily to keep all microsoft compliance integrations provisioned. - --------- Co-authored-by: Lucas Rodriguez <lucas@fleetdm.com> |
||
|---|---|---|
| .. | ||
| api | ||
| assets | ||
| config | ||
| generators/landing-page | ||
| scripts | ||
| tasks | ||
| views | ||
| .editorconfig | ||
| .eslintignore | ||
| .eslintrc | ||
| .gitignore | ||
| .htmlhintrc | ||
| .lesshintrc | ||
| .npmrc | ||
| .sailsrc | ||
| app.js | ||
| Gruntfile.js | ||
| package.json | ||
| Procfile | ||
| README.md | ||
fleetdm.com
This is where the code for the public https://fleetdm.com website lives.
Bugs
To report a bug or make a suggestion for the website, create an issue in the fleet GitHub repository.
Testing locally
See https://fleetdm.com/handbook/digital-experience#test-fleetdm-com-locally
Deploying the website
To deploy changes to the website to production, merge changes to the main branch. If the changes affect the website's code, or touch any files that the website relies on to build content, such as the query library, osquery schema, docs, handbook, articles, etc., then the website will be redeployed.
Wondering how this works? This is implemented in a GitHub action in this repo. Check out the code there to see how it works! For help understanding what
sails runandnpm runcommands in there do, check the scripts inwebsite/package.jsonand inwebsite/scripts/.
Changing the database schema
To deploy new code to production that relies on changes to the database schema or other external systems (e.g. Stripe), first put the website in "maintenance mode" in Heroku. Then, make your changes in the database schema. Next, if you have a script to fix/migrate existing data, go ahead and run it now. (e.g. sails run fix-or-migrate-existing-data). Then, merge your changes and wait for the deploy to finish. Finally, switch off "maintenance mode" in Heroku.
Note that entering maintenance mode prevents visitors from using the website, so it should be used sparingly, and ideally at low-traffic times of day.
Warning: Doing an especially sensitive schema migration? There is a potential timing issue to consider, thanks to an infrastructure change that eliminated downtime during deploys by using Heroku's built-in support for hot-swapping. Read more in https://github.com/fleetdm/fleet/issues/6568#issuecomment-1211503881
Wiping the production database
I hope you know what you're doing. The "easiest" kind of database schema migration:
sails_datastores__default__url='REAL_DB_URI_HERE' sails run wipe
Then when you see the sailboat, hit CTRL+C to exit. All done!