Plugins architecture and development environment #93
Comments
|
Any installed module running in Kong can just require the DAO or create a DB access and do whatever they want. Permissions need to be defined on the DB, example for Cassandra: https://www.datastax.com/documentation/cql/3.0/cql/cql_reference/list_permissions_r.html Note: the Cassandra lua driver does not support authentication. |
thibaultcha
added
the
idea/new plugin
thibaultcha
changed the title
Proper architecture and CLI update for plugin-specific migrations. This is the first step in separating the plugins out of the core repo as planed for 0.5.0. It is related to #93. This is implemented by using the same table as before (`schema_migrations`) to keep track of the executed migrations, except that each plugin and the core itself all have their own row. For simplifications, migrations (plugins or core) now live in a single file. The `database` folder disappeared for core and the migration lives in the DAO. Plugins have migrations in a `migration` folder, named after the type of the database (`cassandra.lua` currently). For now, only the keyauth plugin has its own migrations. The `kong migrations up|down` commands slightly changed. It takes a `-t` parameter to specify which migrations to run (core or a plugin name) and is running all migrations by default. `kong migrations list` lists all executed migration for the core and all plugins. - Needs tests (integration) - Old unit tests were removed - `database` was removed - `kong migrations` slightly changed
Proper architecture and CLI update for plugin-specific migrations. This is the first step in separating the plugins out of the core repo as planed for 0.5.0. It is related to #93. This is implemented by using the same table as before (`schema_migrations`) to keep track of the executed migrations, except that each plugin and the core itself all have their own row. For simplifications, migrations (plugins or core) now live in a single file. The `database` folder disappeared for core and the migration lives in the DAO. Plugins have migrations in a `migration` folder, named after the type of the database (`cassandra.lua` currently). For now, only the keyauth plugin has its own migrations. The `kong migrations up|down` commands slightly changed. It takes a `-t` parameter to specify which migrations to run (core or a plugin name) and is running all migrations by default. `kong migrations list` lists all executed migration for the core and all plugins. - Needs tests (integration) - Old unit tests were removed - `database` was removed - `kong migrations` slightly changed
Proper architecture and CLI update for plugin-specific migrations. This is the first step in separating the plugins out of the core repo as planed for 0.5.0. It is related to #93. This is implemented by using the same table as before (`schema_migrations`) to keep track of the executed migrations, except that each plugin and the core itself all have their own row. For simplifications, migrations (plugins or core) now live in a single file. The `database` folder disappeared for core and the migration lives in the DAO. Plugins have migrations in a `migration` folder, named after the type of the database (`cassandra.lua` currently). For now, only the keyauth plugin has its own migrations. The `kong migrations up|down` commands slightly changed. It takes a `-t` parameter to specify which migrations to run (core or a plugin name) and is running all migrations by default. `kong migrations list` lists all executed migration for the core and all plugins. - Needs tests (integration) - Old unit tests were removed - `database` was removed - `kong migrations` slightly changed
Proper architecture and CLI update for plugin-specific migrations. This is the first step in separating the plugins out of the core repo as planed for 0.5.0. It is related to #93. This is implemented by using the same table as before (`schema_migrations`) to keep track of the executed migrations, except that each plugin and the core itself all have their own row. For simplifications, migrations (plugins or core) now live in a single file. The `database` folder disappeared for core and the migration lives in the DAO. Plugins have migrations in a `migration` folder, named after the type of the database (`cassandra.lua` currently). For now, only the keyauth plugin has its own migrations. The `kong migrations up|down` commands slightly changed. It takes a `-t` parameter to specify which migrations to run (core or a plugin name) and is running all migrations by default. `kong migrations list` lists all executed migration for the core and all plugins. - Needs tests (integration) - Old unit tests were removed - `database` was removed - `kong migrations` slightly changed
Proper architecture and CLI update for plugin-specific migrations. This is the first step in separating the plugins out of the core repo as planed for 0.5.0. It is related to #93. This is implemented by using the same table as before (`schema_migrations`) to keep track of the executed migrations, except that each plugin and the core itself all have their own row. For simplifications, migrations (plugins or core) now live in a single file. The `database` folder disappeared for core and the migration lives in the DAO. Plugins have migrations in a `migration` folder, named after the type of the database (`cassandra.lua` currently). For now, only the keyauth plugin has its own migrations. The `kong migrations up|down` commands slightly changed. It takes a `-t` parameter to specify which migrations to run (core or a plugin name) and is running all migrations by default. `kong migrations list` lists all executed migration for the core and all plugins. - Needs tests (integration) - Old unit tests were removed - `database` was removed - `kong migrations` slightly changed
Proper architecture and CLI update for plugin-specific migrations. This is the first step in separating the plugins out of the core repo as planed for 0.5.0. It is related to Kong#93. This is implemented by using the same table as before (`schema_migrations`) to keep track of the executed migrations, except that each plugin and the core itself all have their own row. For simplifications, migrations (plugins or core) now live in a single file. The `database` folder disappeared for core and the migration lives in the DAO. Plugins have migrations in a `migration` folder, named after the type of the database (`cassandra.lua` currently). For now, only the keyauth plugin has its own migrations. The `kong migrations up|down` commands slightly changed. It takes a `-t` parameter to specify which migrations to run (core or a plugin name) and is running all migrations by default. `kong migrations list` lists all executed migration for the core and all plugins. - Needs tests (integration) - Old unit tests were removed - `database` was removed - `kong migrations` slightly changed Former-commit-id: 1be811953b825e97f7139e05a2b1b294ccd407b3
The question here is whether the plugins are trusted or not. If not, it would require sandboxing all plugin code. If they are trusted, then the above requirements can be dropped. |
|
To be trusted, we would need to review the code of each plugin - it logically makes sense to have them sandboxed. |
|
I'm not sure about that. Sandboxing is hard (even impossible to catch all evils). What are the use cases for using Kong? I cannot imagine some dynamic environment where plugins come and go all the time. Most of the time it's an administrator of some service that sets it up once. So fairly static. Or am I missing something? An alternative could be for Mashape/Kong to host a rocksserver containing all the reviewed and approved plugins, though reviewing and updating might be a huge effort. |
This is true. It would make logically sense to have them sandboxed, but the implementation may be hard.
In the future we could build something like https://atmospherejs.com/ where users can submit their own plugins and install them. It's still a little bit too far from now, but if that's the case then security could be a concern. Because all of this is still in the air, we could talk about it when we finally decide what to do a few months from now. |
thibaultcha
added
task/feature
thibaultcha
added
area/plugins-dev-api
and removed
area/plugins
task/feature
|
I think it's fair to say that Kong has a plugin architecture by now. :) |
* ci(docker) login to docker hub * ci(cache) rebuild the base images to clear stale cache
Kong needs to expose a documented API to allow the creation of plugins of any kind. The Plugins API should expose what functionalities and functions Kong core is programmatically exposing to Plugins, in order for them to be able to interact with the system.
It makes sense to start this conversation sooner than later to avoid rewriting the plugins if the API changes.
Below is a list of operations plugins should be able to perform:
locationsthat are handled by the plugin. Some plugins, like an OAuth server, need to be able to create new nginxlocations, like/oauth-callback./apis/{API_ID}/keyauth/Below is a list of operations plugins are not allowed to do:
Location entries
A quick note on the location entries editing. This feature doesn't necessarily need to change the nginx configuration and it shouldn't, since it can be handle programmatically by reading the requested
urland pass the execution to the appropriate handler.The text was updated successfully, but these errors were encountered: