Git Product home page Git Product logo

vault-ui's Introduction

Vault-UI Logo

Run Status Join the chat at https://gitter.im/vault-ui/Lobby

Vault-UI

A beautiful way to manage your Hashicorp Vault

Features

  • Easy to deploy as Web App
  • Desktop version works on Mac, Linux and Windows
  • Material UI Design
  • Integrated JSON Editor
  • Written in React

Installation

Desktop Version

Vault-UI Desktop is available for the following operating systems:

  • Windows
  • MacOS
  • Linux (32bit and 64bit AppImage)

Download the latest version from the release page and install/run the software

Web Version

Vault-UI can be deployed as a shared web app for your organization

Docker images are automatically built using an automated build on Docker Hub. We encourage that versioned images are used for production.

To run Vault-UI using the latest Docker image:

docker run -d \
-p 8000:8000 \
--name vault-ui \
djenriquez/vault-ui

Advanced configuration options

By default, connection and authentication parameters must be configured by clicking on the configuration cog on the login page. Using environment variables (via docker), an administrator can pre-configure those parameters.

Example command to pre-configure the Vault server URL and authentication method

docker run -d \
-p 8000:8000 \
-e VAULT_URL_DEFAULT=http://vault.server.org:8200 \
-e VAULT_AUTH_DEFAULT=GITHUB \
--name vault-ui \
djenriquez/vault-ui

Supported environment variables:

  • PORT Sets the port for Vault-UI to listen on. (Default 8000)
  • CUSTOM_CA_CERT Pass a self-signed certificate that the system should trust.
  • NODE_TLS_REJECT_UNAUTHORIZED Disable TLS server side validation. (ex. vault deployed with self-signed certificate). Set to 0 to disable.
  • VAULT_URL_DEFAULT Sets the default vault endpoint. Note: protocol part of the url is mandatory. Example: http://10.0.0.1:8200
  • VAULT_AUTH_DEFAULT Sets the default authentication method type. See below for supported authentication methods.
  • VAULT_AUTH_BACKEND_PATH Sets the default backend path. Useful when multiple backends of the same type are mounted on the vault file system.
  • VAULT_SUPPLIED_TOKEN_HEADER Instructs Vault-UI to attempt authentication using a token provided by the client in the specified HTTP request header.

This defaults can be overridden if the user fills out the endpoint and auth method manually.

Current supported login methods:

Current supported management of backend auth methods:

In some cases, users might want to use middleware to authenticate into Vault-UI for purposes like SSO. In this case, the VAULT_SUPPLIED_TOKEN_HEADER may be populated with the name of the header that contains a token to be used for authentication.

Usage

Basic policy for Vault-UI users

A user/token accessing Vault-UI requires a basic set of capabilities in order to correctly discover and display the various mounted backends. Please make sure your user is granted a policy with at least the following permissions:

JSON

{
  "path": {
    "auth/token/lookup-self": {
      "capabilities": [
        "read"
      ]
    },
    "sys/capabilities-self": {
      "capabilities": [
        "update"
      ]
    },
    "sys/mounts": {
      "capabilities": [
        "read"
      ]
    },
    "sys/auth": {
      "capabilities": [
        "read"
      ]
    }
  }
}

HCL

path "auth/token/lookup-self" {
    capabilities = [ "read" ]
}

path "sys/capabilities-self" {
    capabilities = [ "update" ]
}

path "sys/mounts" {
    capabilities = [ "read" ]
}

path "sys/auth" {
    capabilities = [ "read" ]
}

Secrets

Secrets are now managed using the graphical josdejong/jsoneditor JSON editor. Schema validation is enforced on policies to aid the operator in writing correct syntax.

Secrets also are accessible directly by key from a browser by navigating to the URI /secrets/<backendtype>/<mountpoint>/key. For example, if you have a generic secret key of /hello/world/vault using the generic mount secret/, one can navigate to this directly through http://vault-ui.myorg.com/secrets/secret/hello/world/vault.

Root key bias

By default, secrets will display as their raw JSON value represented by the data field in the HTTP GET response metadata. However, users can apply a "Root Key" bias to the secrets through the settings page. The "Root Key" will be used when reading, creating and updating secrets such that the value displayed in the UI is the value stored at the "Root Key". For example, if the secret at secret/hello is { "value": "world" }, setting the "Root Key" to value will update the UI such that the secret will display as simply "world" instead of { "value": "world" }.

Policies

Policies are managed also using the josdejong/jsoneditor JSON editor. Currently, GitHub and raw Tokens are the only supported authentication backends for associated policies.

Token Management

Users have the ability to create and revoke tokens, manage token roles and list accessors. The following permissions are needed at minimum for this feature:

JSON:

{
  "path": {
     "auth/token/accessors": {
       "capabilities": [
         "sudo",
         "list"
       ]
    },
     "auth/token/lookup-accessor/*": {
       "capabilities": [
         "read"
       ]
    }
  }
}

HCL

path "auth/token/accessors" {
    capabilities = [ "sudo", "list" ]
}

path "auth/token/lookup-accessor/*" {
    capabilities = [ "read" ]
}

Response Wrapping

Vault-UI supports response-wrapping of secrets in generic backends. Wrapping custom JSON data is also supported.

Development

Install the yarn package manager

With Docker

The command below will use Docker Compose to spin up a Vault dev server and a Vault UI server that you can log into with username "test" and password "test":

./run-docker-compose-dev

If major changes are made, be sure to run docker-compose build to rebuild dependencies.

Without Docker

The following will spin up a Vault UI server only. It will not set up Vault for you:

yarn run dev-pack &
yarn start

Licensing

Vault-UI is licensed under BSD 2-Clause. See LICENSE for the full license text.

Donations

Vault-UI maintainers are humbly accepting donations as a way of saying thank you!

vault-ui's People

Contributors

aedades avatar albuch avatar alexunwin avatar bloo avatar boeboe avatar deejross avatar djenriquez avatar fengor avatar ipedrazas avatar joraff avatar lcgkm avatar lewispeckover avatar lingrino avatar lucretius avatar michaelkunze avatar msabramo avatar msessa avatar mtak avatar protetore avatar robertlippens avatar tallpauley avatar wgx731 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

vault-ui's Issues

Support multiple backends

currently it looks like only the "root" backend is available, would it be possible to display all backends so that secrets can be managed in other generic backends?

the api call for this would be v1/sys/mounts you could then give the option to select each backend

Policy with glob character does not work correctly

Hello,

My access control policy is shown below

path "secret/foo/*" {
  policy = "write"
}

and I log in to vault-ui, but "foo" is not displayed in the Secrets. When the path is set to "secret/*", "foo" is displayed. Is the glob character handled correctly ?

Thanks.

Login Error

First off, thanks for open sourcing this! Looks great.

I seem to be unable to use this to log into our Vault servers. I've tried running it locally & in our Nomad scheduler. AFAICT, the app doesn't seem to be submitting my credentials to Vault. And all the logs give me is this:

To start debugging, open the following URL in Chrome:
    chrome-devtools://devtools/bundled/inspector.html?experiments=true&v8only=true&ws=127.0.0.1:9229/76febf4b-3300-4cf1-8dec-94dda4486828
Vault UI listening on: 8000
Debugger attached.
(node:65559) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 2): TypeError: Cannot read property 'status' of undefined
(node:65559) DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
(node:65559) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 4): TypeError: Cannot read property 'status' of undefined
(node:65559) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 6): TypeError: Cannot read property 'status' of undefined
(node:65559) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 8): TypeError: Cannot read property 'status' of undefined

I'll try to debug this further, but I was wondering if you have any suggestions?

Manage userpass users?

Apparently it's not currently possible to manage users of the userpass auth backend.

Is this correct or do I need to configure something?

Splash screen images broken

Hey, looks like hashicorp changed up their website and now the V on the vault UI splash screen is missing!

Secret Backend Description in UI - Feature request

The vault mount supports a description -description=<desc> field.

It would be great if we could get that description in the UI header, perhaps under the "Browse secrets" text currently there or in place of the "Here you can browse, edit, create and delete secrets" text.

Confirmation of secret change - Feature request

First off, great job! I really appreciate the work. Would it be possible to add a confirmation when changing a secret? It seems too easy to accidentally overwrite a secret. This might be more my use case than others, but I have a lot secrets that just get read and I want to avoid them being inadvertently changed when a user is copy/pasting them.

Two ideas:

  1. Just a simple confirmation box before saving
  2. Have the secrets displayed in a modal, non-editable mode which requires clicking an edit button to make changes.

unable to browse cubbyhole secrets

From the CLI I created some cubbyhole secrets for a given token.

When logging in to vault-ui using that same token, unable to see anything in cubbyhole

using self signed ssl cert

The UI return 504 from the vault. and log is full with (node:32) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 64): TypeError: Cannot read property 'status' of undefined

Error: Request failed with status code 504

Read policy required on sys/mounts for 1.0.0

Using an instance of the 1.0.0 version with the same configuration and pointed at the same Vault I am unable to see any secrets, while it works on an 0.1.0 instance. I'm authenticating with LDAP which works, however any subsequent requests for secrets don't show anything beyond ROOT.

The vault audit logs for a 0.1.0 working request look like:

{"time":"2017-02-07T23:43:23Z","type":"request","auth":{"display_name":"ldap-<username>","policies":["<policy>","default"],"metadata":{"policies":"<policy>","username":"<username>"}},"request":{"operation":"list","client_token":"hmac-sha256:40cabdda25bd27e0a43b67f6a9ae57ef86bae1e0a22430195f7f9c1fd25ff144","path":"secret/","data":null,"remote_address":"<ipaddress>"},"error":""}

while the same broken request in 1.00 looks like:

{"time":"2017-02-07T23:44:02Z","type":"request","auth": "display_name":"","policies":null,"metadata":null},"request":{"operation":"read","client_token":"hmac-sha256:35b28f2f6aa4c47d635e7d9aab2e4481add6cb53c6deac3597df8c1c151556bd","path":"sys/mounts","data":null,"remote_address":"<ipaddress>"},"error":"permission denied"}

It looks like supporting multiple default backends causes this, so adding a read policy to sys/mounts fixed this for me. I can't see any mention in the documentation though, would suggest you add it!

Secret Change Review w/ JsonDiffPatch

I think it'd be great to have an option for an additional modal after editing a secret or policy (or any JSON for that matter) that shows a diff of the changes w/ jsondiffpatch.

The option would also change the edit modal's "SUBMIT" text to "REVIEW", and then the following modal with the diff would have "CANCEL" and "SUBMIT".

I think this would be a nice option to limit potential dangerous mistakes. I might have some time to work on this one soon, it's a building block for my use case of vault as a decent UI password manager.

Handling 307 Redirects

I've noticed that in a cluster setup (i.e. two Vault servers, one is active the other is passive) Vault-UI doesn't seem to handle the 307 redirects when it hits the passive instance. The UI seems to stall at whatever it was trying to do and it sometimes returns a Network Error message. I can verify this by pointing it directly at the passive instance and watching the logs:

IP1 - - [07/Apr/2017:00:52:28 +0000] "GET /v1/sys/policy HTTP/1.1" 307 0 "https://vault.service.[dc].consul/sys/policies" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Firefox/45.0" "IP2"
IP1 - - [07/Apr/2017:00:52:49 +0000] "POST /v1/sys/capabilities-self HTTP/1.1" 307 0 "https://vault.service.[dc].consul/auth/token/token/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Firefox/45.0" "IP2"

I'd like to be able to point Vault-UI at our Consul DNS address so I don't need to change it if one instance goes down.

Ability to add a name to a token

Hello,

Can you add the ability to add a name when creating a token? (-display-name="name" parameter for vault token-create command)
This would make it possible to differentiate the tokens in the list with the field " Display name".

Regards.

TLS handshake error with Vault 0.7.0

I've got my Kube POD all running with Vault, Vault-UI, and an nginx-based SSL proxy. I'm using a valid Lets Encrypt-based cert in Vault, and I can remotely talk to Vault (exposed on default port 8200) with the CLI. I was able to init, unseal, configure github auth and related group/policy, and auth with my github access key, all from the Vault CLI remotely (from a trusted IP I'm permitting into the Kube service in front of Vault. So, I know Vault is working great.

In addition, I can hit the Vauilt-UI default page just fine (using SSL via my nginx SSL proxy with the same valid Lets Encrypt cert mentioned above) from the same trusted public IP, and it's just prompting me for a github access token and says failure to parse when I paste it in.

<snip>@Ubuntu:~/github/techops/environments$ vault auth -method=github token=<snip>
Successfully authenticated! You are now logged in.
The token below is already saved in the session. You do not
need to "vault auth" again with the token.
token: <snip>
token_duration: 604799
token_policies: [default engineering-policy]

However, Vault-UI running in the same Kube POD is set to talk to Vault on "https://localhost:8200". Because this will result in a cert validation failure, I've set the ENVVAR "NODE_TLS_REJECT_UNAUTHORIZED" to 0, and I even tried dropping Vault's minimum TLS version from the default (1.2) to 1.1. However, no matter what, I can't get Vault-UI to talk to the localhost Vault, and I keep seeing this error in the Vault logs:

2017/04/29 08:20:40 http: TLS handshake error from 10.20.0.1:33748: EOF

Nothing else is talking to Vault except Vault-UI in this case, so I'm pretty sure this is an issue with Vault-UI not being able to TLS handshake with Vault on localhost. I verified from my nginx SSL proxy container's shell, running in the same POD, that I can use "openssl s_client -connect localhost:8200" and I can connect just fine and I receive the SSL cert that I expect (though it doesn't verify because I'm connecting to localhost, not the actual FQDN on the certificate. The var I've set for the Vault-UI container, NODE_TLS_REJECT_UNAUTHORIZED, should disable the need for Vault-UI to validate the cert on localhost. However, I'm still getting that TLS handshake error no matter what.

Any ideas on why Vault-UI would have issues handshaking with Vault? I've read the docs several times to see if I'm missing something but I don't see anything.

Here is my Kube POD config:

{
    "kind": "Deployment",
    "apiVersion": "extensions/v1beta1",
    "metadata": {
        "name": "vault-dc",
        "labels": {
            "app": "vault",
            "vault-dc": "true",
            "cluster": "vault-dc",
            "load-balancer-vault": "true",
            "replication-controller": "vault-dc-v000",
            "stack": "dc",
            "version": "0"
        }
    },
    "spec": {
        "replicas": 1,
        "selector": {
            "matchLabels": {
                "app": "vault",
                "vault-dc": "true",
                "cluster": "vault-dc",
                "stack": "dc",
                "version": "0"
            }
        },
        "template": {
            "metadata": {
                "annotations": {
                    "name": "vault-dc"
                },
                "labels": {
                    "app": "vault",
                    "vault-dc": "true",
                    "cluster": "vault-dc",
                    "load-balancer-vault": "true",
                    "replication-controller": "vault-dc-v000",
                    "stack": "dc",
                    "version": "0"
                }
            },
            "spec": {
                "containers": [{
                    "name": "vault-dc",
                    "image": "vault:0.7.0",
                    "args": ["server"],
                    "securityContext": {
                        "capabilities": {
                            "add": [
                                "IPC_LOCK"
                            ]
                        }
                    },
                    "livenessProbe":{
                        "tcpSocket":{
                            "port": 8200
                        },
                        "initialDelaySeconds": 30,
                        "timeoutSeconds": 2
                    },
                    "ports": [{
                        "containerPort": 8200,
                        "protocol": "TCP"
                    }],
                    "env": [{
                        "name": "VAULT_LOCAL_CONFIG",
                        "valueFrom": {
                            "configMapKeyRef": {
                                "name": "vaultconfig",
                                "key": "config"
                            }
                        }
                    }],
                    "volumeMounts": [{
                        "name": "ssl-vault-secret",
                        "mountPath": "/etc/secrets/ssl",
                        "readOnly": true
                    },{
                        "name": "cloudstorage-oauth-credentials",
                        "mountPath": "/etc/secrets/cloudstorage",
                        "readOnly": true
                    }]
                },{
                    "name": "vaultui-dc",
                    "image": "djenriquez/vault-ui:latest",
                    "livenessProbe":{
                        "tcpSocket":{
                            "port": 8000
                        },
                        "initialDelaySeconds": 30,
                        "timeoutSeconds": 2
                    },
                    "env": [{
                        "name": "VAULT_URL_DEFAULT",
                        "value": "https://localhost:8200"
                    },{
                        "name": "VAULT_AUTH_DEFAULT",
                        "value": "GITHUB"
                    },{
                        "name": "NODE_TLS_REJECT_UNAUTHORIZED",
                        "value": "0"
                    }]
                },{
                    "name": "sslwebproxy-dc",
                    "image": "${CONTAINER_REGISTRY}/${GCP_REGISTRY_PROJECT}/sslwebproxy:latest",
                    "livenessProbe": {
                        "tcpSocket": {
                            "port": 443
                        },
                        "initialDelaySeconds": 10,
                        "timeoutSeconds": 5
                    },
                    "readinessProbe": {
                        "tcpSocket": {
                            "port": 443
                        },
                        "initialDelaySeconds": 10,
                        "timeoutSeconds": 2
                    },
                    "env": [{
                        "name": "SERVICE_HOST_ENV_NAME",
                        "value": "localhost"
                    },{
                        "name": "SERVICE_PORT_ENV_NAME",
                        "value": "8000"
                    },{
                        "name": "ENABLE_SSL",
                        "value": "true"
                    },{
                        "name": "DISABLE_SSL_BACKEND",
                        "value": "true"
                    },{
                        "name": "ENABLE_BASIC_AUTH",
                        "value": "false"
                    }],
                    "volumeMounts": [{
                        "name": "ssl-vault-secret",
                        "mountPath": "/etc/secrets",
                        "readOnly": true
                    }],
                    "ports": [{
                        "name": "https",
                        "containerPort": 443,
                        "protocol": "TCP"
                    }],
                    "resources": {}
                }],
                "volumes": [{
                    "name": "ssl-vault-secret",
                    "secret": {
                        "secretName": "ssl-vault-secret"
                    }
                },{
                    "name": "cloudstorage-oauth-credentials",
                    "secret": {
                        "secretName": "cloudstorage-oauth-credentials"
                    }
                },{
                    "name": "ssl-certs",
                    "hostPath": {
                        "path": "/etc/ssl/certs"
                    }
                }]
            }
        },
        "strategy": {
            "type": "Recreate"
        }
    }
}

Example screenshot showing adding a key is misleading/incorrect

There is an example image in the docs that shows a screenshot of the "New Key" dialog with a key of "hello" and a value of "my secret":

New Secret dialog

But when I try to do this, no key is added and there is no error displayed in the Web UI but the console log has:

vault-ui_1                           | Error: Request failed with status code 400
vault-ui_1                           |     at createError (/app/node_modules/axios/lib/core/createError.js:15:15)
vault-ui_1                           |     at settle (/app/node_modules/axios/lib/core/settle.js:18:12)
vault-ui_1                           |     at IncomingMessage.handleStreamEnd (/app/node_modules/axios/lib/adapters/http.js:186:11)
vault-ui_1                           |     at emitNone (events.js:91:20)
vault-ui_1                           |     at IncomingMessage.emit (events.js:185:7)
vault-ui_1                           |     at endReadableNT (_stream_readable.js:974:12)
vault-ui_1                           |     at _combinedTickCallback (internal/process/next_tick.js:74:11)
vault-ui_1                           |     at process._tickCallback (internal/process/next_tick.js:98:9)
vault-ui_1                           | (node:31) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 42): TypeError: Converting circular structure to JSON

It seems that the problem is that value has to be JSON, because if I do this,

screen shot 2016-12-03 at 4 52 00 pm

then it works:

screen shot 2016-12-03 at 4 52 51 pm

Credentials are being compromised in plain text when POST /login

When I'm trying to authenticate with username / password or token, if I will inspect element, my credentials are being exposed in plain text.
It would be nice to mask the password key:

POST
XHR
https://vault-ui.example.org/login [HTTP/2.0 400 Bad Request 22ms]
Headers
POST
Response
Call Stack
{"VaultUrl":"https://vault.example.org","Creds":{"Type":"USERNAMEPASSWORD","Username":"dasd","password":"233"}}

They are also exposed in any action to make after you authenticate:

https://vault-ui.example.org/policy?vaultaddr=https://example.kpn.org&policy=stdrusers&token=<token_in_plain_text>

vault-ui in https

Hello,

I have not seen any information to pass vaul-ui in https?
Is it possible ? If so, would it be possible to have documentation?

Regards.

Unable to Login - Request failed with status code 503

Hello,

In my test environment, I am running Docker Containers of Vault 0.6.4 with Consul 0.7.2 backend and have created few users which are working as expected on CLI.

🍺  ~$ vault auth -method=userpass username=vikas
Password (will be hidden):
Successfully authenticated! You are now logged in.
The token below is already saved in the session. You do not
need to "vault auth" again with the token.
token: b0459465-e88a-0f49-54ee-13f908605e64
token_duration: 2764799
token_policies: [admins default]
🍺  ~$
🍺  ~$ vault write secret/project/myproject/hello value=vikas
Success! Data written to: secret/project/myproject/hello
🍺  ~$

But, I am unable to login thru the UI. These are the errors of docker container

# docker logs -f vault-ui
Error: Request failed with status code 503
    at createError (/app/node_modules/axios/lib/core/createError.js:15:15)
    at settle (/app/node_modules/axios/lib/core/settle.js:18:12)
    at IncomingMessage.handleStreamEnd (/app/node_modules/axios/lib/adapters/http.js:186:11)
    at emitNone (events.js:91:20)
    at IncomingMessage.emit (events.js:185:7)
    at endReadableNT (_stream_readable.js:974:12)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)

The error on the web UI is Authorization failed

Cheers.

Serverless design

Reading through the server-side node app source code it looks like most of the routes are simply proxying the client request to the vault server with no further modifications.

Given a scenario where the vault server is exposed directly to clients via a reverse proxy (nginx or such) adding the Access-Control-Allow-Origin: * header, it could be possible to adapt vault-ui react code to speak directly to the vault server without the need for the node server-side component.
This enables scenarios such as deploying to S3 static sites.

Is it something you guys would be interested in further exploring?

Change docroot from / to /ui

Hello,

Is it possible to change the docroot of the application from / to /ui (or any) ?
I am trying to run it behind load balancer but the app is always calling back the requests to / (even if i rewrite the location in my configuration)

Search/Filter Keys

It would be perfect if we could search/filter keys in the respective interface for a given back-end.

Add Web CLI

I believe there would be significant benefits in adding a web cli to Vault-UI that allows users to execute Vault CLI commands. This would give users the ability to perform any Vault operation through the UI even if the UI doesn't directly provide an interface for it.

The CLI would use the same token as the UI, which will automatically limit the users to their assigned policies. This could be the feature that makes Vault-UI the "one-stop-shop" while we improve the rest of the experience building interfaces.

Thoughts @msessa-cotd @Lucretius @alexunwin

collaboration with jippi/hashi-ui

Hi @djenriquez

vault-ui looks amazing! I don't know if you know about my project hashi-ui - but its a UI similar to your vault-ui, just for nomad and consul.

The long-term goal is to include the full hashi-stack into one glorious UI, and even longer term, have nice cross-interaction between the different tools, as most people use almost all of the hashi-stack together anyway.
For those that don't use the full hashi-stack, the ui will still act as a separate per-app interface, stand-alone in one binary, enabling multiple backends in a simple env or cli flag.

One thing currently missing is the vault part of the ui, so wonder if you would be interesting in joining forces and getting consul/nomad/vault into one perfect and beautiful package, and centralize the effort of hashi-stack interfaces into one project, rather than many disperse ones.

I've been talking to hashicorp on making my hashi-ui a official hashicorp endorsed project, even further (hopefully) centralizing the effort on hashi interfaces.

I really want to run hashi-ui as a open project, where there is no single dictator on the project, and make it a truly accessible and open project for everyone to contribute to.

We both use reactjs + material-ui for the frontend, so seem to be some nice benefits in merging the projects. Where we diverge is on the backend part, I'm using Go, as it allows the interface to utilize the official API SDKs from hashicorp, as well as producing one binary with all assets and backend (no cors, enable read-only access and much easier operational management)

I'm available for a chat if you like the idea, either on GitHub, the hashi-ui gitter channel ( https://gitter.im/hashi-ui/Lobby ) or slack (jippi on hangops and gcp)

/Christian

Set vault cluster address permanently

It would be great to be able to set the cluster address as an admin so each user doesn't have to.

Either in a configuration file, environment variable or the UI works for me.

Kudos for the project, works perfectly for my needs.

Implement token management

Currently Vault-UI does not allow authorized users to manage tokens in Vault. Users still need to access Vault through the CLI to generate tokens and such. This feature request will allow users to perform all available token operations such as viewing, creating, modifying and revoking.

Add support for token auth via HTTP Header

I would love if Vault UI could read a Vault token in X-Remote-User (or whatever name) if present, allowing use of custom SSO front-end. In my use case, we would have a SAML 2.0 SSO proxy which could use a hook to get a Vault token for a user and pass it along to Vault UI so that the user wouldn't need to log in again after SSO.

SAML for Vault is sort-of in-progress but the future is unclear due to variance in SAML implementations. The ability to read a Vault token from X-Remote-User would be a nice universal adapter for SSO not-yet-supported by Vault (or never supported by Vault). It doesn't compromise security since Vault tokens can't be forged.

By the way, this UI is the most promising Vault UI i've seen so far. Keep up the good work!

Self-Signed TLS Cert

There doesn't seem to be any option to either pass in a SSL Cert or to ignore TLS to the Vault host. I have a self signed cert that was created through Vault and not sure how I can pass in the key or ignore TLS.

Thanks!

Expose vault's /auth/token/renew-self via vault-ui

Hi vault-ui devs.

We're happily using vault-ui to front all of our vault interactions, so for the most part, we don't use the CLI. But I notice one area of the API which the CLI has a wrapper for and which vault-ui doesn't, namely: the /auth/token/renew-self endpoint.

Is this something that has been given any consideration and/or something you would accept a PR for? I can't guarantee I can get to it or when, but this seems like a feature that would be worth having for our use case at least.

Token can't get Secret/Auth backends - but policy seems correct?

I'm logging in with LDAP and attempting to give my authorized LDAP users basically full rights to as much as possible in vault-ui. I added the policies that vault-ui is requesting for sys/mounts and sys/auth. The admin policy which my LDAP users get has the following:

/*
	This is the "admin" policy. 
	This should only be assigned to human users authenticated by the ldap auth backend.	
*/

path "sys/auth" {
    capabilities = [ "read" ]
}

path "auth/token/create" {
	capabilities = ["create", "read", "sudo", "update", "delete", "list"]
}

path "auth/token/create/*" {
	capabilities = ["create", "read", "sudo", "update", "delete", "list"]
}

path "secret/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

// Administrators have the right to manage policies for apps:

path "sys/policy" {
  capabilities = ["sudo", "create", "read", "update", "delete", "list"]
}

path "sys/policy/*" {
  capabilities = ["sudo", "create", "read", "update", "delete", "list"]
}

path "sys/mounts" {
  capabilities = ["read"]
}
vault policies admin
/*
	This is the "admin" policy. 
	This should only be assigned to human users authenticated by the ldap auth backend.	
*/

path "sys/auth" {
    capabilities = [ "read" ]
}

path "auth/token/create" {
	capabilities = ["create", "read", "sudo", "update", "delete", "list"]
}

path "auth/token/create/*" {
	capabilities = ["create", "read", "sudo", "update", "delete", "list"]
}

path "secret/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}

// Administrators have the right to manage policies for apps:

path "sys/policy" {
  capabilities = ["sudo", "create", "read", "update", "delete", "list"]
}

path "sys/policy/*" {
  capabilities = ["sudo", "create", "read", "update", "delete", "list"]
}

path "sys/mounts" {
  capabilities = ["read"]
}

However, I am still getting the "Your token doesn't have permissions" messages for both secret and auth. I restarted and unsealed Vault, then re-started vault-ui, log out and log back in, but no dice.

Is there some kind of caching, or maybe some oddity of using HCL instead of JSON?

Improve error logging

Had this set up about a month ago and was able to log in fine no problem, using our AD LDAP servers for the auth backend. Did a redeploy 2 weeks ago and since then, when I enter my AD name and password, then hit enter, nothing happens on the UI and I get the below in stdout:

(node:30) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 4): TypeError: Cannot read property 'status' of undefined

:(

Listing many secrets freeze the browser

Hi,

When the list contains more than 200 items, the browser hangs up.
I did some tests and It seems that user experience stay normal under 200 items, above this limit is hardly usable. (listing 5000 items with CLI or directly with API is OK)
Would it possible to add a function to deal with this problem, like pagination or list size limit?

Thanks,

Ability to unwrap token on "Data wrapper" page

Currently it's only possible to wrap some data on the "Data wrapper" page. After wrapping it returns "unwrap" url which is really useful for web app but not for the desktop variant. It would be great to have an ability to paste existing token below "Response wrapping" section & receive original data.

Running in Kubernetes with an nginx-based reverse proxy

Hi,

I'm trying to run this awesome tool in a Kubernetes POD along with containers for vault and nginx. Because (I don't believe) vault-ui supports using SSL (just clear HTTP) and because this will be hosted off-prem, we will be ACL-restricted (by IP) access to the tool and sticking nginx in front of vault-ui to act as an SSL frontend (port 443) and proxy to vault-ui in clear HTTP (on localhost in the same POD) on its default port 8000.

I have everything setup, and it appears to almost be working, but I'm getting a redirect loop from nginx when I passes the request to vault-ui on the backend. Thoughts on what it could be? Happy to provide any/all configs you want, just didn't want to dump anything here up-front to avoid creating a giant post.

Thanks,
-R

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.