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>
all libraries in pkg/* should never be called Fatal()
internally, the console is imported now and it is important
that the failure logging etc is all well controlled.
Bonus: update to latest minio/pkg v1.0.6 to get trial
customer license verification fixes.
- fixed issue when deploying tenant with tls disabled
- applied new design for tenant details and license screens
- added license refresh job to operator console
- added new refresh license endpoint
- console operator not longer store CONSOLE_ACCESS_KEY and
CONSOLE_SECRET_KEY values in the tenant-console-secret
Co-authored-by: Daniel Valdivia <hola@danielvaldivia.com>
* Upgrade to Go 1.16. Remove Go-Bind-assets in favor of embed. Checking Portal-UI Build folder.
* lint
* Remove assets references
* Fixes for sub fs
* Fix lint
iam/policies now support wildcard actions for
all actions such as 's3:Get*', 's3:Put*'
new policies such as CreateBucket now honors
LocationConstraint set but rejecting calls
that do not honor region.
Implemented Log Search API & Prometheus functionality in console, also fixed minor issues in all the platform
Co-authored-by: Benjamin Perez <benjamin@bexsoft.net>
- 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
- update operator version to latest version
- create tenant endpoint now supports multiple TLS certificates for
MinIO TLS configuration
- update certificates endpoint now support multiple TLS certificates
Co-authored-by: Daniel Valdivia <hola@danielvaldivia.com>
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.
This PR adds the following features:
- Allow user to provide its own keypair certificates for enable TLS in
MinIO
- Allow user to configure data encryption at rest in MinIO with KES
- Removes JWT schema for login and instead Console authentication will use
encrypted session tokens
Enable TLS between client and MinIO with user provided certificates
Instead of using AutoCert feature now the user can provide `cert` and
`key` via `tls` object, values must be valid `x509.Certificate`
formatted files encoded in `base64`
Enable encryption at rest configuring KES
User can deploy KES via Console/Operator by defining the encryption
object, AutoCert must be enabled or custom certificates for KES must be
provided, KES support 3 KMS backends: `Vault`, `AWS KMS` and `Gemalto`,
previous configuration of the KMS is necessary.
eg of body request for create-tenant
```
{
"name": "honeywell",
"access_key": "minio",
"secret_key": "minio123",
"enable_mcs": false,
"enable_ssl": false,
"service_name": "honeywell",
"zones": [
{
"name": "honeywell-zone-1",
"servers": 1,
"volumes_per_server": 4,
"volume_configuration": {
"size": 256000000,
"storage_class": "vsan-default-storage-policy"
}
}
],
"namespace": "default",
"tls": {
"tls.crt": "",
"tls.key": ""
},
"encryption": {
"server": {
"tls.crt": "",
"tls.key": ""
},
"client": {
"tls.crt": "",
"tls.key": ""
},
"vault": {
"endpoint": "http://vault:8200",
"prefix": "",
"approle": {
"id": "",
"secret": ""
}
}
}
}
```
`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
````
