Intrinsic support for multiple backends and general restyling

[msessa]

Hi @djenriquez @alexunwin

Note: I'm opening a PR although there is still a bit of work to do here before it can be merged, but this way is easier to discuss changes.

This PR shifts the discovery of secret backends and authentication backend (post-login) to the Menu component, which dynamically renders a nested list of mounted backends.
I believe vault-ui needs to be designed following the core architecture of vault, which allow multiple instances of a backend to be mounted on arbitrary paths in the logical filesystem.
Also I believe it's not the responsibility of the individual backend-interface components to discover their namespaces.

This should make it easier to develop support for other types of secret backends (aws, mysql etc) and authentication backends (userpass, ldap, aws, etc)

Edit: To demonstrate the point above I've moved the GitHub and EC2 components from Policies to the appropriate location for the new model.

You can test all this with

./run-docker-compose-dev

A breakdown of the changes:

• Redesigned left side menu navigation using material-ui components
• Menu entries are dynamically loaded if token has read access to /sys/mounts and /sys/auth otherwise it will fallback to the standard view
• Refactored Secrets page to accommodate this approach
• Redesigned Secrets browser with material-ui components
• Refactored Policies with new layout

It looks like this:

[djenriquez]

Looks fantastic so far @msessa-cotd. I'll dive deeper into the details later tonight, awesome work!

[msessa]

Hi @djenriquez, did you have a chance to take a look? Any thoughts?

[djenriquez]

@msessa-cotd sorry for the delay. I haven't had a chance to take a look yet. I'll make time tonight to do so.

[djenriquez]

@msessa-cotd I'm seeing the added keys you're using to figure out the permissions for secrets navigation, but I do not see the same menu items as the screen shot above. Did you decide to move back on this?

[msessa]

Did you run the run-docker-compose-dev in my branch? I've added a few lines there to mount a second generic backend and create some objects

[djenriquez]

Yup, ran docker-compose build also, which is probably a step we should add to the doc if devs are switching branches with different dependencies:

vault-ui $ git branch
* dynamic_nav

vault-ui $ . run-docker-compose-dev 
------------- docker-compose up -d -------------
Creating network "vaultui_default" with the default driver
Creating vaultui_vault_1
Creating vaultui_vault-ui_1

------------- docker-compose ps -------------
      Name             Command             State              Ports       
-------------------------------------------------------------------------
vaultui_vault-     npm run serve      Up                 0.0.0.0:8000->80 
ui_1                                                     00/tcp           
vaultui_vault_1    docker-            Up                 0.0.0.0:8200->82 
                   entrypoint.sh                         00/tcp           
                   serve ...                                              

------------- vault auth a162c563-6f2f-31ff-6294-2a524194bee3 -------------
Successfully authenticated! You are now logged in.
token: a162c563-6f2f-31ff-6294-2a524194bee3
token_duration: 0
token_policies: [root]

------------- vault status -------------
Sealed: false
Key Shares: 1
Key Threshold: 1
Unseal Progress: 0
Version: 0.6.4
Cluster Name: vault-cluster-773d6d89
Cluster ID: e2779473-4af4-f927-5469-3250646ecd91

High-Availability Enabled: false

------------- vault auth-enable userpass -------------
Successfully enabled 'userpass' at 'userpass'!

------------- vault auth-enable github -------------
Successfully enabled 'github' at 'github'!

------------- vault auth-enable -path=awsaccount1 aws-ec2 -------------
Successfully enabled 'aws-ec2' at 'awsaccount1'!

------------- vault policy-write admin /app/admin.hcl -------------
Policy 'admin' written.

------------- vault write auth/userpass/users/test password=test policies=admin -------------
Success! Data written to: auth/userpass/users/test

------------- vault write secret/test somekey=somedata -------------
Success! Data written to: secret/test

------------- vault mount -path=ultrasecret generic -------------
Successfully mounted 'generic' at 'ultrasecret'!

------------- vault write ultrasecret/moretest somekey=somedata -------------
Success! Data written to: ultrasecret/moretest

------------- vault write ultrasecret/dir1/secret somekey=somedata -------------
Success! Data written to: ultrasecret/dir1/secret

------------- vault write ultrasecret/dir2/secret somekey=somedata -------------
Success! Data written to: ultrasecret/dir2/secret

------------- vault write ultrasecret/dir2/secret2 somekey=somedata -------------
Success! Data written to: ultrasecret/dir2/secret2

------------- vault write ultrasecret/admincantlistthis/butcanreadthis somekey=somedata -------------
Success! Data written to: ultrasecret/admincantlistthis/butcanreadthis

------------- vault write ultrasecret/admincantreadthis somekey=somedata -------------
Success! Data written to: ultrasecret/admincantreadthis

------------- Vault Root Token -------------
vault_1     | Root Token: a162c563-6f2f-31ff-6294-2a524194bee3

[msessa]

Ooops I commented out webpack in docker-compose.yml and forgot to revert it before I committed.

Pull now

[djenriquez]

The left hand menu is definitely looking better. The core real estate seems to have regressed though with some views looking like this:

I think if we maximize the real estate to somehow remove the "modal", it'll present itself better.

The new distinction between namespaces and actual secrets is great:

However, the new navigation bar for secrets seems unintuitive since users still enter namespaced keys with / but the display shows arrows:

vs

Lastly, the use of the toastbar is exactly what I visioned to help provide better feedback to the user. I also like the experience of denied access to secrets and name spaces. Nice stuff!

Do you agree with my feedback on the navigation bar and core real estate?

[msessa]

I agree. I'll make the breadcrumb nav better in the secret browser.
Also some of the views like secret wrapping, github, EC2 need to be retouched to match the new styling (the one I've done for secrets and policies).

I've also designed a "policy picker" component since choosing from existing policies is a very common task in vault. You can check it out if you pull now and go in Token/Create New Token or Role. It looks like this:

Also I want to extend all the components to be addressable by URL like the secrets page.
For example you should be able to point to
https://vaultui/system/policies/policyname
and the policy editor should pop up.

Anyway if you like what's been done so far, I can continue working on it and finish the remaining bits, once we merge this branch I will start writing new components for other secret/auth backends.

I'll have to prioritise the ones my company uses most (EC2 auth, RADIUS auth, IAM creds) but eventually I'd like to see interfaces for all supported backend.

[djenriquez]

Thats fantastic, and yes, prioritize what you need. When things settle a bit with my new job I'll have time to be more active, but really appreciate the work!

[msessa]

Hi @djenriquez,

I've completed most of the restyling around the app. Would you be able to take a look?

There's also a few new substantial changes:

• Validity of token is now checked on app mount
• App header refactored and extended with current identity information
  
• Policies are now URL addressable
• Welcome screen now displays warning messages if backends cant be listed (./run-docker-compose-dev and login with u:lame p:lame to preview)
• Preserve the original path when unauthenticated users are redirected to login
• New generic SecretWrapper component. This component can be reused in the app to wrap any type of data.
• Integrate SecretWrapper in generic secret component
• Integrate SecretWrapper in response wrapping page (renamed to Data Wrapper)
• PolicyPicker integration in token/role creation dialog

The SecretWrapper component is particularly interesting because it's coupled with a very basic router endpoint /unwrap which displays a readonly json editor with the unwrapped data. It doesn't require any authentication to vault UI.

Example wrapping an existing secret:

The provided URL can be used with no prior authentication to display the wrapped secret.

Let me know your thoughts.

Cheers

[djenriquez]

@msessa-cotd

Without looking at the code, the experience is most definitely improved, absolutely awesome stuff! The token, username and connected Vault address is great information for the user to have. Response wrapping also has a better experience now.

The only thing I find questionable is the modal style view of the core real estate. I believe it would look and feel better if it was maximized somehow. Ideally, the display would take up the entire core space without floating over a white background. Was there a reason for the floating-style displays vs just using the space?

Also for language/spelling, let's stick with US English to remain consistent with the Vault project itself. (Customize vs customize, Preferences vs Preferencies, etc)

None-the-less, bravo 🎉!

[msessa]

hi @djenriquez

I've reclaimed some space on the page and taken away most of the depth effect.

Also fixed those australian spellings ;) sorry, force of habit

[djenriquez]

Looks much better. I think you missed one with the Tokens page.

Otherwise, LGTM 👍

[djenriquez]

After these two PRs are merged in, PTAL at Release Draft 1.1.0 and make sure the release notes are accurate. I think you should have access to that.

[msessa]

Fixed layout for the tokens page.

Can you guys consider merging?