- Update operator dependency
- Don't store policy on session token, instead obtain it during session
validation
Signed-off-by: Lenin Alevski <alevsk.8772@gmail.com>
Security Tab allow users to set various configurations related to TLS
certificates for MinIO and Console
- Enable/Disable AutoCert
- Add/Delete MinIO and Console Certificates
- Add/Delete MinIO and Console CA Certificates
Signed-off-by: Lenin Alevski <alevsk.8772@gmail.com>
Operator UI - Provide and store License key
- New License section in Operator UI will allow user to provide the
license key via input form
- New License section in Operator UI will allow the user to fetch the
license key using subnet credentials
- Console backend has to verify provided license is valid -
https://godoc.org/github.com/minio/minio/pkg/licverifier#example-package
- Console backend has to store the license key in k8s secrets
Operator UI - Set license to tenant during provisioning
- Check if license key exists in k8s secret during tenant creation
- If License is present attach the license-key jwt to the new console
tenant via an environment variable
Operator UI - Set license for an existing tenant
- Tenant view will display information about the current status of the
Tenant License
- If Tenant doesn't have a License then Operator-UI will allow to attach
new license by clicking the Add License button
- Console backend will extract the license from the k8s secret and save
the license-key jwt in the tenant console environment variable and
redeploy
- 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>
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
`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
````
