* Allow multiple IDPs config to be passed via struct
* This removes support for ENV based IDP configuration for console
* Ensure default scopes are used if none are given
* Add display name field for provider config
- Added flag CONSOLE_OBJECT_BROWSER_ONLY=on to trigger between console mode & Object Browser only
- Hidden not necessary buttons for object browse
- STS Login
Signed-off-by: Benjamin Perez <benjamin@bexsoft.net>
Signed-off-by: Daniel Valdivia <18384552+dvaldivia@users.noreply.github.com>
Similar to MinIO now it's possible to configure webhooks to log all
triggered errors and incomming requests via env variables:
```
CONSOLE_LOGGER_WEBHOOK_ENABLE_<ID>
CONSOLE_LOGGER_WEBHOOK_ENDPOINT_<ID>
CONSOLE_LOGGER_WEBHOOK_AUTH_TOKEN_<ID>
CONSOLE_LOGGER_WEBHOOK_CLIENT_CERT_<ID>
CONSOLE_LOGGER_WEBHOOK_CLIENT_KEY_<ID>
CONSOLE_LOGGER_WEBHOOK_QUEUE_SIZE_<ID>
CONSOLE_AUDIT_WEBHOOK_ENABLE_<ID>
CONSOLE_AUDIT_WEBHOOK_ENDPOINT_<ID>
CONSOLE_AUDIT_WEBHOOK_AUTH_TOKEN_<ID>
CONSOLE_AUDIT_WEBHOOK_CLIENT_CERT_<ID>
CONSOLE_AUDIT_WEBHOOK_QUEUE_SIZE_<ID>
```
Signed-off-by: Lenin Alevski <alevsk.8772@gmail.com>
To enable this feature you need `CONSOLE_IDP_CALLBACK_DYNAMIC=on`
```
export CONSOLE_IDP_URL=https://gitlab.com/.well-known/openid-configuration
export CONSOLE_IDP_CLIENT_ID="b0088c3836bb029393942f71ed7c8ac0add7f0856e6c86e67b0ff98f85c48658"
export CONSOLE_IDP_SECRET="ed72087b37624e89816ac27c1355420902045274edd7baad2ae29b1b0e8436fe"
export CONSOLE_IDP_SCOPES="openid,profile,email"
export CONSOLE_IDP_USERINFO="on"
export CONSOLE_IDP_CALLBACK_DYNAMIC=on
console srv
```
if this becomes a common practice, we should enable this as default in future.
This PR includes many fixes and refactors for oauth2 authentication and
login endpoints, ie:
- Invalid login returns `403` instead of `500` error
- Removed the session token from console/operator `user credentials
login`, `oauth flow login` and `change-password` api responses
- Removed session token from localStorage
- Added styles for oauth_callback page and display more descriptive
errors for debugging
- Success logins returns `204` instead of `200`
- Removed unused swagger apis and code from both, operator and console
projects
- Operator `Oauth2` login flow was not validating anything, now it does
Signed-off-by: Lenin Alevski <alevsk.8772@gmail.com>
- `CONSOLE_STS_DURATION_IN_SECONDS` env renamed to `CONSOLE_STS_DURATION` to support more time formats
Signed-off-by: Lenin Alevski <alevsk.8772@gmail.com>
- 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>
- Update transport to use the same from Console in IDP Auth
- Validate provided idp URL
Co-authored-by: Harshavardhana <harsha@minio.io>
Signed-off-by: Ricardo Katz <rkatz@vmware.com>
Signed-off-by: Lenin Alevski <alevsk.8772@gmail.com>
Co-authored-by: Ricardo Katz <rkatz@vmware.com>
Co-authored-by: Harshavardhana <harsha@minio.io>
With support for GitLab OpenID service,
we need to make sure to support userInfo
endpoint for this MinIO server requires that
access_token is additionally sent along with
id_token as before to make sure we can fetch
additional claims from /userinfo endpoint.
This PR brings support on console for this
feature.
Refer https://github.com/minio/minio/pull/12469
Embedded console was ignoring values set by CONSOLE_PBKDF_PASSPHRASE and
CONSOLE_PBKDF_SALT for generating new session tokens, derivedKey is used
to encrypt/decrypt session tokens generated by console
Signed-off-by: Lenin Alevski <alevsk.8772@gmail.com>
x/oauth2 always wants a context with a custom http client embedded
when performing various requests. Ensure that the custom http client is
passed when requesting for a token.
- 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.
User secret key is not really need it to be stored inside the encrypted
session key, since the `change-password` endpoint requires the user to
provide the current `secret key` that password will be used to
initialize a new minio client then we will leverage on the
`SetUser` operation, this api only works with actual user credentials
and not sts credentials
- 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>
- 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
Generate 16 bytes IV instead of an IV of 32 bytes (and then use half of it) when using ChaCha20 to
encrypt tokens, this is to prevent tokens to become malleable.
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": ""
}
}
}
}
```
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
````
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.
