fleet
fleet copied to clipboard
fleetdm
Use secrets (Wi-Fi credentials, API tokens, etc.) in scripts or profiles
prospect-numa: No gong recording. Customer's words from Slack: "The main thing we’ll need is a way to securely send sensitive data, like API tokens or software license keys, to endpoints while keeping everything encrypted until it gets there. This ensures the data stays safe during deployment and is only decrypted by the endpoint. For example, we could use this for licensing enterprise apps, interacting with APIs directly from the client, or securely managing local account passwords. It could also be useful for delivering database credentials or cloud service tokens that apps need."- @noahtalerman: Users will expect to be able to pass an API token in a script and that API token won't be visible in plain text when an IT admin views or downloads the script in Fleet.
- @noahtalerman: The key is that only the workstation can see the secret (no other human or machine). In
prospect-numa's use case, for example, they might be installing an app that needs a license. To do this, you want to make a call to an API as part of the app’s pre-install script (requires an API token). They uploaded this script to a GitLab repo. They add the API token to the GitLab repo's secrets. They want the API token to be in variable format e.g.$API_TOKEN_HEREin the repo and in the Fleet when an IT admin views/downloads a script.
- @noahtalerman: The key is that only the workstation can see the secret (no other human or machine). In
- @allenhouchins: Other MDM solutions support variables in scripts. Some people use this feature to inject secrets that are encypted into the scripts. For example, calling the an MDM solution's API (needs an API token) in the script.
- @nonpunctual: Users will expect that end users will see variable names in place of the secrets if they open up the script files that exist on their machines.
- @nonpunctual Users will expect to be able to use the same variables across multiple scripts and profiles, and change the secret in one place.
- @nonpunctual: Users will expect to pass an API token in a script and be able to use that token to call internal systems, such as Fleet's own API, from the end user's computer. Then use that information in the MDM for a dynamic custom column (extension attribute), and then use that column to build a dynamic grouping based on the results from the script. For example, get data from some log to build a group in my MDM.
User stories
- #23238
- #27351
Secrets kept secure, Through the cloud, decoded pure, In Fleet we ensure.
@AnthonySnyder8 would you fill in the (private) Gong link in the description when you have a moment?
Original issue description:
User story: As an IT customer excited about expanding Fleet from MDM to configuration management (replacing a tool like Chef), I want to use Fleet as secrets store, instead of chef, where I can hit the Fleet API and pull in those secrets from anywhere.
Problem
As an IT admin, I could store secrets in a gitops workflow and access them via automations (GH actions). This approach is how Fleet dogfoods our google workspace enrollment token, for example, which is deployed as an element of a configuration profile.
I may want to deploy a secret independently of a configuration element that Fleet manages (config profile, script, or software application). In this case, the secret becomes a first class citizen much like a config profile, script, or software application.
Potential solutions
A good example of how configuration management tools manage secrets is the Chef data bag. Fleet should be able to declaratively configure secrets stored in a library or repo via gitops (on a per host basis) as well as store these secrets internally to the Fleet server db to control encryption and decryption on the host
Hi @rachaelshaw, the prospect did not allow us to record most of our conversations with them, and I believe the relevant call for this was not recorded. Do you have any additional context here for Rachel, @dherder ?
Up to @AnthonySnyder8 to find best verbatim context (from notes, Slack, wherever) and include in the description above.
@AnthonySnyder8 I moved the context you added below for safekeeping. It's a good start but it doesn't give us example use cases. Up to you on pulling our Slack convo into a Google doc that we can share w/ the rest of the team.
Goal:
- To deploy encrypted keys or secrets that are securely transmitted and decrypted on endpoints What:
- Show logging history of who managed/viewed secrets 1. Passphrase 2. Utilizing our software license keys 3. Fleet would live in Repo 1. Prospect: I would like to see it within Fleet, living in an encrypted repo 4. How Fleet orchestrates the encryption and decryption 1. Vault instance and orchestrating this via GH actions, also has done this with chef / databags 5. Prospect: can put in deployment process - who hiding from 1. Fleet: don’t want an admin to view keys? I.e. no UI inspection - correct 6. Use GH secrets? Also could use data bags in Chef 1. Problem: plain text in Fleet plist 2. Fleet: this shouldn’t happen with MDM features 3. Prospect: check packages to see if in plain text 4. In GH actions log, the design of redacted is good to follow 5. Prospect: want to be able to debug With Puppet: https://www.puppet.com/docs/puppet/8/securing-sensitive-data.html
- @noahtalerman: Users will expect to be able to pass an API token in a script and that API token won't be visible in plain text when an IT admin views or downloads the script in Fleet.
- @noahtalerman: The key is that only the workstation can see the secret (no other human or machine). In
prospect-numa's use case, for example, they might be installing an app that needs a license. To do this, you want to make a call to an API as part of the app’s pre-install script (requires an API token). They uploaded this script to a GitLab repo. They add the API token to the GitLab repo's secrets. They want the API token to be in variable format e.g.$API_TOKEN_HEREin the repo and in the Fleet when an IT admin views/downloads a script.
- @noahtalerman: Confirmed w/
propspect-numathat this is the desired workflow. Assigning myself to this feature request while we work w/prospect-numato get their feedback and see if Fleet is missing anything.
@AnthonySnyder8 here's the latest findings from conversations w/ prospect-numa. I assigned myself to the issue.
cc @rachaelshaw
@zayhanlon in Fleet 4.62, we shipped the ability to hide secrets, added via Fleet's YAML (GitOps), in configuration profiles and scripts (user story here).
We think this addressed the problem numa described in this feature request.
Can you please show the following demo video to numa and collect any feedback from them. Are we missing anything?
Demo video: https://drive.google.com/file/d/1FsqEEkh6H5KOHP4Wf7PnJnRzL_f_KF3-/view?usp=sharing
Figma wireframes for what this could look like in the UI is here. Feedback from Harry and Brock:
After talking to Brock: I actually think a slight change to the secrets section, where we have a single page in settings but it's still broken down by team.
SECRETS
Team: Workstations
- secret A
- secret B
- secret C Team: Workstations (Canary)
- secret A Team: Servers
- secret A
I think having them on a single page where they can be viewed easily rather than having to switch from team to team might be better but it's hard to know which is better in use. Will there be a way to create / modify with API? If so, maybe page per team will be ok. If not (which makes sense from security perspective) I think 1 page would be more like secrets vault products I have seen / used.
Moving the old user stories list out of the issue description to below. User stories that contribute to this request now live in the "Sub-issues" section.
User stories
- #23238
- #29235
- #27351
- @zayhanlon: feedback from
numacall today: "if a change is made to a CI/CD process, i would expect all variables to change/update with it"
- @zayhanlon: feedback from
@zayhanlon the first part of this request, "Use secrets in scripts or profiles in the UI" #29235 shipped in 4.73. We think there's some additional work to be done; see https://github.com/fleetdm/fleet/issues/27351