3aee6ec464
* Fix UI when editing database roles
When using a database role the UI will try to update the database connection
associated to the role. This is to make sure that the role is allowed to
use this connection:
async _updateAllowedRoles(store, { role, backend, db, type = 'add' }) {
const connection = await store.queryRecord('database/connection', { backend, id: db });
const roles = [...connection.allowed_roles];
const allowedRoles = type === 'add' ? addToArray([roles, role]) : removeFromArray([roles, role]);
connection.allowed_roles = allowedRoles;
return connection.save();
},
async createRecord(store, type, snapshot) {
const serializer = store.serializerFor(type.modelName);
const data = serializer.serialize(snapshot);
const roleType = snapshot.attr('type');
const backend = snapshot.attr('backend');
const id = snapshot.attr('name');
const db = snapshot.attr('database');
try {
await this._updateAllowedRoles(store, {
role: id,
backend,
db: db[0],
});
} catch (e) {
throw new Error('Could not update allowed roles for selected database. Check Vault logs for details');
}
return this.ajax(this.urlFor(backend, id, roleType), 'POST', { data }).then(() => {
// ember data doesn't like 204s if it's not a DELETE
return {
data: assign({}, data, { id }),
};
});
},
This is intended to help the administrator as the role will only work if
it is allowed by the database connection.
This is however an issue if the person doing the update does not have
the permission to update the connection: they will not be able to use
the UI to update the role even though they have the appropriate permissions
to do so (using the CLI or the API will work for example).
This is often the case when the database connections are created by a
centralized system but a human operator needs to create the roles.
You can try this with the following test case:
$ cat main.tf
resource "vault_auth_backend" "userpass" {
type = "userpass"
}
resource "vault_generic_endpoint" "alice" {
depends_on = [vault_auth_backend.userpass]
path = "auth/userpass/users/alice"
ignore_absent_fields = true
data_json = jsonencode({
"policies" : ["root"],
"password" : "alice"
})
}
data "vault_policy_document" "db_admin" {
rule {
path = "database/roles/*"
capabilities = ["create", "read", "update", "delete", "list"]
}
}
resource "vault_policy" "db_admin" {
name = "db-admin"
policy = data.vault_policy_document.db_admin.hcl
}
resource "vault_generic_endpoint" "bob" {
depends_on = [vault_auth_backend.userpass]
path = "auth/userpass/users/bob"
ignore_absent_fields = true
data_json = jsonencode({
"policies" : [vault_policy.db_admin.name],
"password" : "bob"
})
}
resource "vault_mount" "db" {
path = "database"
type = "database"
}
resource "vault_database_secret_backend_connection" "postgres" {
backend = vault_mount.db.path
name = "postgres"
allowed_roles = ["*"]
verify_connection = false
postgresql {
connection_url = "postgres://username:password@localhost/database"
}
}
$ terraform apply --auto-approve
then using bob to create a role associated to the `postgres` connection.
This patch changes the way the UI does the update: it still tries to
update the database connection but if it fails to do so because it does not
have the permission it just silently skip this part and updates the role.
This also update the error message returned to the user in case of issues
to include the actual errors.
* Add changelog
* Also ignore error when deleting a role
* Address code review comments
---------
Co-authored-by: Chelsea Shaw <82459713+hashishaw@users.noreply.github.com>
Table of Contents
Vault UI
This README outlines the details of collaborating on this Ember application.
Ember CLI Version Upgrade Matrix
| Vault Version | Ember Version |
|---|---|
| 1.15.x | 4.12.0 |
| 1.14.x | 4.4.0 |
| 1.13.x | 4.4.0 |
| 1.12.x | 3.28.5 |
| 1.11.x | 3.28.5 |
| 1.10.x | 3.28.5 |
| 1.9.x | 3.22.0 |
| 1.8.x | 3.22.0 |
| 1.7.x | 3.11.0 |
Prerequisites
You will need the following things properly installed on your computer.
In order to enforce the same version of yarn across installs, the yarn binary is included in the repo
in the .yarn/releases folder. To update to a different version of yarn, use the yarn policies set-version VERSION command. For more information on this, see the documentation.
Running a Vault Server
Before running Vault UI locally, a Vault server must be running. First, ensure
Vault dev is built according the the instructions in ../README.md.
- To start a single local Vault server:
yarn vault - To start a local Vault cluster:
yarn vault:cluster
These commands may also be aliased on your local device.
Running the UI locally
To spin up the UI, a Vault server must be running (see previous step).
All of the commands below assume you're in the ui/ directory.
These steps will start an Ember CLI server that proxies requests to port 8200, and enable live rebuilding of the application as you change the UI application code. Visit your app at http://localhost:4200.
- Install dependencies:
yarn
- Run Vault UI and proxy back to a Vault server running on the default port, 8200:
yarn start
If your Vault server is running on a different port you can use the long-form version of the npm script:
ember server --proxy=http://localhost:PORT
Mirage
Mirage can be helpful for mocking backend endpoints. Look in mirage/handlers for existing mocked backends.
Run yarn with mirage: yarn start:mirage handlername
Where handlername is one of the options exported in mirage/handlers/index
Building Vault UI into a Vault Binary
We use the embed package from Go >1.20 to build the static assets of the Ember application into a Vault binary.
This can be done by running these commands from the root directory:
make static-dist
make dev-ui
This will result in a Vault binary that has the UI built-in - though in
a non-dev setup it will still need to be enabled via the ui config or
setting VAULT_UI environment variable.
Development
Quick commands
| Command | Description |
|---|---|
yarn start |
start the app with live reloading |
yarn start:mirage <handler> |
start the app with the mocked mirage backend, with handler provided |
make static-dist && make dev-ui |
build a Vault binary with UI assets (run from root directory not /ui) |
ember g component foo -ir core |
generate a component in the /addon engine |
yarn test:quick -f='<test name>' -s |
run tests in the browser, filtering by test name |
yarn lint:js |
lint javascript files |
Code Generators
Make use of the many generators for code, try ember help generate for more details. If you're using a component that can be widely-used, consider making it an addon component instead (see this PR for more details)
eg. a reusable component named foo that you'd like in the core engine (read more about Ember engines here).
ember g component foo -ir core
The above command creates a template-only component by default. If you'd like to add a backing class, add the -gc flag:
ember g component foo -gc -ir core
Running Tests
Running tests will spin up a Vault dev server on port :9200 via a pretest script that testem (the test runner) executes. All of the acceptance tests then run, which proxy requests back to that server.
yarn run test:ossyarn run test:oss -sto keep the test server running after the initial run.yarn run test -f="policies"to filter the tests that are run.-fgets passed into QUnit'sfilterconfig
Linting
yarn lint:jsyarn lint:hbsyarn lint:fix
Contributing / Best Practices
Hello and thank you for contributing to the Vault UI! Below is a list of patterns we follow on the UI team to keep in mind when contributing to the UI codebase. This is an ever-evolving process, so we welcome any comments, questions or general feedback.
Remember prefixing your branch name with
ui/will run UI tests and skip the go tests. If your PR includes backend changes, do not prefix your branch, instead add theuilabel on github. This will trigger the UI test suite to run, in addition to the backend Go tests.