Previously every Handler function was receiving the session token in the
form of a jwt string, in consequence every time we want to access the
encrypted claims of the jwt we needed to run a decryption process,
additionally we were decrypting the jwt twice, first at the session
validation then inside each handler function, this was also causing a
lot of using related to the merge between m3 and mcs
What changed:
Now we validate and decrypt the jwt once in `configure_mcs.go`, this
works for both, mcs (console) and operator sessions, and then pass the
decrypted claims to all the functions that need it, so no further token
validation or decryption is need it.
* Support for MinDNS
* mindns option
* Added minDNS to summary table
* Validations of configure page
* Added create label & removed console logs
* Adding login workaround
* Added min limits to inputs
* Fixed issue with sizes
* Removed empty values from review page
* Added zone names
* Added validation to zones selector
* Fixed issue with back button in zones page
* Changed validation for zones filter & simplified clean zones
* Changed CredentialsPrompt to be a global component.
* Added assets
* Added hover to table & removed view button
* Added view links & actions to tables
* Added links for cloud & console in table
* Fixed position of progress bar
* Added advanced mode to wizard
* Added "zebra-style" tables
* Added servers field to simple form
* Fixes for demo
* Tweaks
* updated assets
* remove hardcoded bypass
* Address Comments
Co-authored-by: Benjamin Perez <benjamin@bexsoft.net>
fixes: https://github.com/minio/mcs/issues/184
There was a bug in Safari in related to the browser not setting the session token
correctly in localstorage, this was because we were using
window.location.href for redirect instead of history.push after login, the redirect execution was faster
was faster that the promise function getting the response after the login request
and it seems to be that Safari will kill all current request of a
window when the page is getting redirected.
Test this:
Try to sign-in using Safari browser (latest version is recommended)
`MCS` will authenticate against `Mkube`using bearer tokens via HTTP
`Authorization` header. The user will provide this token once
in the login form, MCS will validate it against Mkube (list tenants) and
if valid will generate and return a new MCS sessions
with encrypted claims (the user Service account token will be inside the
JWT in the data field)
Kubernetes
The provided `JWT token` corresponds to the `Kubernetes service account`
that `Mkube` will use to run tasks on behalf of the
user, ie: list, create, edit, delete tenants, storage class, etc.
Development
If you are running mcs in your local environment and wish to make
request to `Mkube` you can set `MCS_M3_HOSTNAME`, if
the environment variable is not present by default `MCS` will use
`"http://m3:8787"`, additionally you will need to set the
`MCS_MKUBE_ADMIN_ONLY=on` variable to make MCS display the Mkube UI
Extract the Service account token and use it with MCS
For local development you can use the jwt associated to the `m3-sa`
service account, you can get the token running
the following command in your terminal:
```
kubectl get secret $(kubectl get serviceaccount m3-sa -o
jsonpath="{.secrets[0].name}") -o jsonpath="{.data.token}" | base64
--decode
```
Then run the mcs server
```
MCS_M3_HOSTNAME=http://localhost:8787 MCS_MKUBE_ADMIN_ONLY=on ./mcs
server
```
Self-signed certificates and Custom certificate authority for Mkube
If Mkube uses TLS with a self-signed certificate, or a certificate
issued by a custom certificate authority you can add those
certificates usinng the `MCS_M3_SERVER_TLS_CA_CERTIFICATE` env variable
````
MCS_M3_SERVER_TLS_CA_CERTIFICATE=cert1.pem,cert2.pem,cert3.pem ./mcs
server
````
Changed bucket detail styles & fixed minor issues for edit access policy & usage report not shown in page
Co-authored-by: Benjamin Perez <benjamin@bexsoft.net>
Remove ping check and instead use a context that will be canceled
if it the client sends a close message or an error occurs on reading.
The context will be used to cancel all functions using it.
This PR sets the initial version of the ACL for mcs, the idea behind
this is to start using the principle of least privileges when assigning
policies to users when creating users through mcs, currently mcsAdmin policy uses admin:*
and s3:* and by default a user with that policy will have access to everything, if want to limit
that we can create a policy with least privileges.
We need to start validating explicitly if users has acccess to an
specific endpoint based on IAM policy actions.
In this first version every endpoint (you can see it as a page to),
defines a set of well defined admin/s3 actions to work properly, ie:
```
// corresponds to /groups endpoint used by the groups page
var groupsActionSet = iampolicy.NewActionSet(
iampolicy.ListGroupsAdminAction,
iampolicy.AddUserToGroupAdminAction,
//iampolicy.GetGroupAdminAction,
iampolicy.EnableGroupAdminAction,
iampolicy.DisableGroupAdminAction,
)
// corresponds to /policies endpoint used by the policies page
var iamPoliciesActionSet = iampolicy.NewActionSet(
iampolicy.GetPolicyAdminAction,
iampolicy.DeletePolicyAdminAction,
iampolicy.CreatePolicyAdminAction,
iampolicy.AttachPolicyAdminAction,
iampolicy.ListUserPoliciesAdminAction,
)
```
With that said, for this initial version, now the sessions endpoint will
return a list of authorized pages to be render on the UI, on subsequent
prs we will add this verification of authorization via a server
middleware.
Uses a similar approach as Trace and Console Logs by using
websockets. It also includes the integration with the UI which
needs 3 input fields that are sent as query parameters.
Changed modal forms to contain scrollbars where the inputs are, so this way the titles and buttons get always visible.
Co-authored-by: Benjamin Perez <benjamin@bexsoft.net>
Co-authored-by: Daniel Valdivia <hola@danielvaldivia.com>
