Doesn't the use of the CLI require the manual setup process in the demo video? With the login and configure? If I don't want to manually setup each machine, is there any war around it? I saw there are service tokens, but I think there might be a bit of chicken and egg issue, where I need to pass secret tokens to access the system to pass secrets with.
An enterprise (self hosted) offering is probably what my admittedly niche uses would require. Just kind of spit-balling some ideas really, to see where things are headed.
Any concept of separation of duties? Like Doppler level Owner / Admins who don't have access to the configs, they just create projects and give users access to edit the configs with them. Or audit ability, where someone can't see the secrets, just who made changes when?
How long is the history on each config? Is it permanent history? Or just some time frame?
Or how about universal configs? Occasionally I have something like an api url, a git repo, or an artifactory url. Which rarely change, but would like synced across all environments in a project. Or even across projects. I know I could cut and paste the value across environments, but mistakes can be made.
Lots of really great questions in here! Starting at the top-
The process demoed in the video is for user-based auth. Service tokens can be issued programmatically and provide read-only access to one config. You can pass these into your environment via puppet and other configuration tools, or even via LDAP, in much the same way you bootstrap other OS config like SSH keys.
I really like your thoughts around more niche access roles, and it's definitely where we're headed. Admittedly our RBAC is currently more limited with a basic Member, Admin, Owner model. We do have existing audit capabilities for monitoring secrets changes (without revealing the actual secrets) and support shipping those logs to Slack or a webhook.
Audit history is based on your specific plan[0], but we currently offer up to a year. Some customers do have requirements for longer time periods and we can easily configure that for them.
Regarding your last point, this is what we refer to as secret referencing. You can absolutely reference secrets across different configs and projects to avoid repeating common values. Here's our announcement from when we shipped this feature back in August[1].
An enterprise (self hosted) offering is probably what my admittedly niche uses would require. Just kind of spit-balling some ideas really, to see where things are headed.
Any concept of separation of duties? Like Doppler level Owner / Admins who don't have access to the configs, they just create projects and give users access to edit the configs with them. Or audit ability, where someone can't see the secrets, just who made changes when?
How long is the history on each config? Is it permanent history? Or just some time frame?
Or how about universal configs? Occasionally I have something like an api url, a git repo, or an artifactory url. Which rarely change, but would like synced across all environments in a project. Or even across projects. I know I could cut and paste the value across environments, but mistakes can be made.