fbd1c5f51a
This commit refactors the certificate management implementation
in the `certs` package such that multiple certificates can be
specified at the same time. Therefore, the following layout of
the `certs/` directory is expected:
```
certs/
│
├─ public.crt
├─ private.key
├─ CAs/ // CAs directory is ignored
│ │
│ ...
│
├─ example.com/
│ │
│ ├─ public.crt
│ └─ private.key
└─ foobar.org/
│
├─ public.crt
└─ private.key
...
```
However, directory names like `example.com` are just for human
readability/organization and don't have any meaning w.r.t whether
a particular certificate is served or not. This decision is made based
on the SNI sent by the client and the SAN of the certificate.
***
The `Manager` will pick a certificate based on the client trying
to establish a TLS connection. In particular, it looks at the client
hello (i.e. SNI) to determine which host the client tries to access.
If the manager can find a certificate that matches the SNI it
returns this certificate to the client.
However, the client may choose to not send an SNI or tries to access
a server directly via IP (`https://<ip>:<port>`). In this case, we
cannot use the SNI to determine which certificate to serve. However,
we also should not pick "the first" certificate that would be accepted
by the client (based on crypto. parameters - like a signature algorithm)
because it may be an internal certificate that contains internal hostnames.
We would disclose internal infrastructure details doing so.
Therefore, the `Manager` returns the "default" certificate when the
client does not specify an SNI. The default certificate the top-level
`public.crt` - i.e. `certs/public.crt`.
This approach has some consequences:
- It's the operator's responsibility to ensure that the top-level
`public.crt` does not disclose any information (i.e. hostnames)
that are not publicly visible. However, this was the case in the
past already.
- Any other `public.crt` - except for the top-level one - must not
contain any IP SAN. The reason for this restriction is that the
Manager cannot match a SNI to an IP b/c the SNI is the server host
name. The entire purpose of SNI is to indicate which host the client
tries to connect to when multiple hosts run on the same IP. So, a
client will not set the SNI to an IP.
If we would allow IP SANs in a lower-level `public.crt` a user would
expect that it is possible to connect to MinIO directly via IP address
and that the MinIO server would pick "the right" certificate. However,
the MinIO server cannot determine which certificate to serve, and
therefore always picks the "default" one. This may lead to all sorts
of confusing errors like:
"It works if I use `https:instance.minio.local` but not when I use
`https://10.0.2.1`.
These consequences/limitations should be pointed out / explained in our
docs in an appropriate way. However, the support for multiple
certificates should not have any impact on how deployment with a single
certificate function today.
Co-authored-by: Harshavardhana <harsha@minio.io>
|
||
|---|---|---|
| .github | ||
| browser | ||
| buildscripts | ||
| cmd | ||
| dockerscripts | ||
| docs | ||
| mint | ||
| pkg | ||
| .dockerignore | ||
| .gitignore | ||
| .golangci.yml | ||
| .goreleaser.yml | ||
| .mailmap | ||
| .nancy-ignore | ||
| code_of_conduct.md | ||
| CONTRIBUTING.md | ||
| CREDITS | ||
| Dockerfile | ||
| Dockerfile.arm64.release | ||
| Dockerfile.arm.release | ||
| Dockerfile.dev | ||
| Dockerfile.dev.browser | ||
| Dockerfile.mint | ||
| Dockerfile.ppc64le.release | ||
| Dockerfile.release | ||
| Dockerfile.s390x.release | ||
| go.mod | ||
| go.sum | ||
| LICENSE | ||
| main.go | ||
| Makefile | ||
| minio.spec | ||
| NOTICE | ||
| README_zh_CN.md | ||
| README.md | ||
| ruleguard.rules.go | ||
| SECURITY.md | ||
| staticcheck.conf | ||
MinIO Quickstart Guide
MinIO is a High Performance Object Storage released under Apache License v2.0. It is API compatible with Amazon S3 cloud storage service. Use MinIO to build high performance infrastructure for machine learning, analytics and application data workloads.
Docker Container
Stable
docker run -p 9000:9000 \
-e "MINIO_ACCESS_KEY=AKIAIOSFODNN7EXAMPLE" \
-e "MINIO_SECRET_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" \
minio/minio server /data
Edge
docker run -p 9000:9000 \
-e "MINIO_ACCESS_KEY=AKIAIOSFODNN7EXAMPLE" \
-e "MINIO_SECRET_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" \
minio/minio:edge server /data
NOTE: Docker will not display the default keys unless you start the container with the
-it(interactive TTY) argument. Generally, it is not recommended to use default keys with containers. Please visit MinIO Docker quickstart guide for more information here
macOS
Homebrew (recommended)
Install minio packages using Homebrew
brew install minio/stable/minio
minio server /data
NOTE: If you previously installed minio using
brew install miniothen it is recommended that you reinstall minio fromminio/stable/minioofficial repo instead.
brew uninstall minio
brew install minio/stable/minio
Binary Download
| Platform | Architecture | URL |
|---|---|---|
| Apple macOS | 64-bit Intel | https://dl.min.io/server/minio/release/darwin-amd64/minio |
chmod 755 minio
./minio server /data
GNU/Linux
Binary Download
| Platform | Architecture | URL |
|---|---|---|
| GNU/Linux | 64-bit Intel | https://dl.min.io/server/minio/release/linux-amd64/minio |
wget https://dl.min.io/server/minio/release/linux-amd64/minio
chmod +x minio
./minio server /data
| Platform | Architecture | URL |
|---|---|---|
| GNU/Linux | ppc64le | https://dl.min.io/server/minio/release/linux-ppc64le/minio |
wget https://dl.min.io/server/minio/release/linux-ppc64le/minio
chmod +x minio
./minio server /data
Microsoft Windows
Binary Download
| Platform | Architecture | URL |
|---|---|---|
| Microsoft Windows | 64-bit | https://dl.min.io/server/minio/release/windows-amd64/minio.exe |
minio.exe server D:\Photos
FreeBSD
Port
Install minio packages using pkg, MinIO doesn't officially build FreeBSD binaries but is maintained by FreeBSD upstream here.
pkg install minio
sysrc minio_enable=yes
sysrc minio_disks=/home/user/Photos
service minio start
Install from Source
Source installation is only intended for developers and advanced users. If you do not have a working Golang environment, please follow How to install Golang. Minimum version required is go1.13
GO111MODULE=on go get github.com/minio/minio
Allow port access for Firewalls
By default MinIO uses the port 9000 to listen for incoming connections. If your platform blocks the port by default, you may need to enable access to the port.
ufw
For hosts with ufw enabled (Debian based distros), you can use ufw command to allow traffic to specific ports. Use below command to allow access to port 9000
ufw allow 9000
Below command enables all incoming traffic to ports ranging from 9000 to 9010.
ufw allow 9000:9010/tcp
firewall-cmd
For hosts with firewall-cmd enabled (CentOS), you can use firewall-cmd command to allow traffic to specific ports. Use below commands to allow access to port 9000
firewall-cmd --get-active-zones
This command gets the active zone(s). Now, apply port rules to the relevant zones returned above. For example if the zone is public, use
firewall-cmd --zone=public --add-port=9000/tcp --permanent
Note that permanent makes sure the rules are persistent across firewall start, restart or reload. Finally reload the firewall for changes to take effect.
firewall-cmd --reload
iptables
For hosts with iptables enabled (RHEL, CentOS, etc), you can use iptables command to enable all traffic coming to specific ports. Use below command to allow
access to port 9000
iptables -A INPUT -p tcp --dport 9000 -j ACCEPT
service iptables restart
Below command enables all incoming traffic to ports ranging from 9000 to 9010.
iptables -A INPUT -p tcp --dport 9000:9010 -j ACCEPT
service iptables restart
Test using MinIO Browser
MinIO Server comes with an embedded web based object browser. Point your web browser to http://127.0.0.1:9000 ensure your server has started successfully.
Test using MinIO Client mc
mc provides a modern alternative to UNIX commands like ls, cat, cp, mirror, diff etc. It supports filesystems and Amazon S3 compatible cloud storage services. Follow the MinIO Client Quickstart Guide for further instructions.
Pre-existing data
When deployed on a single drive, MinIO server lets clients access any pre-existing data in the data directory. For example, if MinIO is started with the command minio server /mnt/data, any pre-existing data in the /mnt/data directory would be accessible to the clients.
The above statement is also valid for all gateway backends.
Upgrading MinIO
MinIO server supports rolling upgrades, i.e. you can update one MinIO instance at a time in a distributed cluster. This allows upgrades with no downtime. Upgrades can be done manually by replacing the binary with the latest release and restarting all servers in a rolling fashion. However, we recommend all our users to use mc admin update from the client. This will update all the nodes in the cluster simultaneously and restart them, as shown in the following command from the MinIO client (mc):
mc admin update <minio alias, e.g., myminio>
NOTE: some releases might not allow rolling upgrades, this is always called out in the release notes and it is generally advised to read release notes before upgrading. In such a situation
mc admin updateis the recommended upgrading mechanism to upgrade all servers at once.
Important things to remember during MinIO upgrades
mc admin updatewill only work if the user running MinIO has write access to the parent directory where the binary is located, for example if the current binary is at/usr/local/bin/minio, you would need write access to/usr/local/bin.mc admin updateupdates and restarts all servers simultaneously, applications would retry and continue their respective operations upon upgrade.mc admin updateis disabled in kubernetes/container environments, container environments provide their own mechanisms to rollout of updates.- In the case of federated setups
mc admin updateshould be run against each cluster individually. Avoid updatingmcto any new releases until all clusters have been successfully updated. - If using
kesas KMS with MinIO, just replace the binary and restartkesmore information aboutkescan be found herex - If using Vault as KMS with MinIO, ensure you have followed the Vault upgrade procedure outlined here: https://www.vaultproject.io/docs/upgrading/index.html
- If using etcd with MinIO for the federation, ensure you have followed the etcd upgrade procedure outlined here: https://github.com/etcd-io/etcd/blob/master/Documentation/upgrades/upgrading-etcd.md
Explore Further
- MinIO Erasure Code QuickStart Guide
- Use
mcwith MinIO Server - Use
aws-cliwith MinIO Server - Use
s3cmdwith MinIO Server - Use
minio-goSDK with MinIO Server - The MinIO documentation website
Contribute to MinIO Project
Please follow MinIO Contributor's Guide
License
Use of MinIO is governed by the Apache 2.0 License found at LICENSE.