Got me thinking about how to integrate secret managers as each cloud provider has it’s own solution (Google, Amazon, DO, etc) and also there are several self-hosted solutions out there(hashicorp vault, doppler, infisical, etc) each one of them handles their API in a different way.
How about creating a small nodejs embedded server based on Server Connect (w/ a subset of actions) that runs in the context of a project?
Then you just need to place hooks all over the UI logic to give ultimate control as how teams interact with Wappler Studio(desktop app).
Examples:
A company might want to restrict everything in the UI except the theme manager to certain users.
A user might have permission to everything except to deploy.
A team can now use a secrets manager to handle secure API keys. (e.g. $_PROJ variables)
CI/CD based on Server Connect actions.
All handled with the familiarity of Server Connect.
Being 100% honest, the reason I didn’t vote for this, is because I didn’t understand anything you said
I hope others and the Wappler team understands what you’re explaining, this went over my head completely
I go as far as defining environment variables for each environment (development, staging, production) for secrets like API keys and stuff. Anything above that is very uncharted territory for me and needs to be explained like I’m 5 (years old)
Alright, let’s imagine that Wappler is like a big playground where you can build cool castles (websites and apps). Now, sometimes, to build these castles, you need special keys (API keys and sensitive information) that only certain people can use.
Different playgrounds might have their own secret hiding spots (secret managers) for these keys. To make it easier for everyone to find and use these keys, we can build a little helper robot (a small Node.js server) that knows where all the hiding spots are and can quickly fetch the keys when needed.
By adding special buttons and switches (hooks) in the playground, we can make sure that only the right kids (users) can access certain parts of the playground or use the special keys. This way, everyone can have fun building castles while keeping the keys safe and secure!
Well secret management differs greatly from environment variables in terms of the management and security features provided, like the ones mentioned below:
Centralized Management: A secrets manager typically offers a centralized platform to securely store and manage secrets like API keys. It provides features like versioning, rotation, and access control, making it easier to handle and update sensitive information.
Encryption and Access Control: Secrets managers employ encryption to protect the stored secrets. They also provide granular access control, allowing specific users or systems to access and use the secrets while keeping others restricted.
Auditability: Secrets managers usually offer audit logs, which help track who accessed or modified the secrets and when. This enhances the security and accountability of secret management.
It would be a nice feature to have this inbuilt in wappler itself
That would be ok, but being able to write your own Server Connect actions that run in the context of a project and adding hooks all over the UI would allow some cool stuff to happen. You can run those SC flows using vm2 to sandbox them and also leverage the newly introduced permissions in nodejs 20.
The idea would be to spin an embedded nodejs server that executes SC flows in the context of a project so you can create your own logic that has certain effects over Wappler’s UI.
These SC flows would have access to a subset of actions that would only make sense in the context of the project. So for instance file access would only be granted to the project folder, but not to the Electron app. This can be done by sandboxing the actions to run in vm/vm2 and also leverage the new permission system that has been introduced recently in node 20 and has been part of Deno since it’s inception.
Besides the subset of current SC actions some new actions could be added to handle CLI interaction, git commands, or docker commands…
This would effectively allow us to create our own deployment process and other automations that need to occur in the context of the project. So basically nocode/lowcode CI/CD for your project. Imagine the possibilities.
This would be useful for solo developers but also for teams. Wappler studio app already queries a backend API for authentication and license checking so maybe from your account dashboard account5.wappler.io you can define who would have write access to the project Server Connect so only you can write actions and push your project Server Connect to the remote git repo.
Wappler on init(or event) would always pull the latest version from your project github repo so all the team has the project SC in sync.
