- enhance logging throughout the codebase
- all packages at pkg/ should never log
or perform log.Fatal() instead packages
should return errors through functions.
- simplified various user, group mapping
and removed redundant functions.
- deprecate older flags like --tls-certificate
--tls-key and --tls-ca as we do not use
them anymore, keep them for backward compatibility
for some time.
- Account change password endpoints
- Change account password modal
- Grouped account settings and service accounts
- Removed the SuperAdmin credentials from almost all places, only
missing place is Oauth login
- Renamed service-accounts UI labels to account in Menu
Co-authored-by: Daniel Valdivia <hola@danielvaldivia.com>
* Move heal and watch to tenant details view on operator-ui
* TLS skip verify in wss/watch endpoint
Use insecure: true in the meantime so the wss/watch endpoint works while
we add support for custotm TLS transport in the S3 client library.
Removed "InsecureSkipVerify: true" from s3AdminClient and s3Client HTTP clients
- We preserve the insecure parameter in the `newS3Config` and `NewAdminClientWithInsecure` functions for debugging and testing purposes.
- By default InsecureSkipVerify is false, therefore in order for Operator-Console to verify the TLS connections to MinIO tenants with self-signed certificates it requires the `ca.crt` or the `public.crt` of the tenant to exists under `~/.console/certs/CAs` which is the right way to do it.
Co-authored-by: Cesar Nieto <ces.nietor@gmail.com>
Co-authored-by: Daniel Valdivia <hola@danielvaldivia.com>
Use insecure: true in the meantime so the wss/watch endpoint works while
we add support for custotm TLS transport in the S3 client library.
Removed "InsecureSkipVerify: true" from s3AdminClient and s3Client HTTP clients
- If MinIO is configured with LDAP then users and groups are external, and
the credentials provided in the CONSOLE_ACCESS_KEY and
CONSOLE_SECRET_KEY env vars will belong to an existing user in the active
directory, therefore we need to authenticate first with
`credentials.NewLDAPIdentity`
- Fixed race condition bug in which TLS RootCAs certs were not loading
correctly (certPool was always null)
- Fixed TLS bug in which if Console was deployed without TLS enabled
RootCAs certs were not loading
- Initialize LDAP Admin credentials once
- Initialize stsClient once
Supports single and multiple objects which needs to be defined by recursive flag.
An object to be deleted needs to be defined by a query parameter, path, since it can be
an object or a folder.
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.
`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
````
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.
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.
Uses same behavior as the Trace feature using websockets.
For displaying it on the UI it needed to handle colors
since the log message comes with unicode colors embbeded
on the message.
Also a special case when an error log comes needed to be handled
to show all sources of the error.
Trace Api uses websocket to send trace information, a
valid jwt token needs to be sent either on the header
or as a cookie of the ws request to start.
Three goroutines are needed to ensure communication
if read hearbeat fails all trace should stop by cancelling
the context. WaitGroups are needed to ensure all
goroutines finish gracefully.
