echo {{ tpl .accessKey $global }} > $MINIO_ACCESSKEY_SECRETKEY_TMP
{{- if .existingSecret }}
cat /config/secrets-svc/{{ tpl .existingSecret $global }}/{{ tpl .existingSecretKey $global }} >> $MINIO_ACCESSKEY_SECRETKEY_TMP
# Add a new line if it doesn't exist
echo >> $MINIO_ACCESSKEY_SECRETKEY_TMP
{{ else }}
echo {{ .secretKey }} >> $MINIO_ACCESSKEY_SECRETKEY_TMP
{{- end }}
{{- if $svc.policy}}
createSvcacct {{ .user }} svc_policy_{{ $idx }}

- Once object lock configuration is set to a bucket
  - New objects inherit the retention settings of the bucket object lock configuration automatically
  - Retention headers can be optionally set while uploading objects

    This is due to an issue of prefix based Matcher() function
    which was incorrectly matching prefix based on resource
    prefixes instead of exact match.
```

- There is always a possibility of a fix that is new, it is advised that the developer must make sure that the fix is sent upstream, reviewed and merged to the master branch.

## Creating a hotfix branch

A subroute on a client must match a subroute on the server. So routes cannot be used for dynamic routing, unlike HTTP.

Handlers should remain backwards compatible. If a breaking API change is required, a new handler ID should be created.

## Setup & Configuration

A **Manager** is used to manage all incoming and outgoing connections to a server.

On startup all remote servers must be specified. 

  -e "MINIO_ROOT_USER=AKIAIOSFODNN7EXAMPLE" \
  -e "MINIO_ROOT_PASSWORD=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" \
  quay.io/minio/minio server /data --console-address ":9001"
```

	  ],
	  "Sid": ""
	}
  ]
}
EOF
```

Create new canned policy by name `getonly` using `getonly.json` policy file.

```
mc admin policy create myminio getonly getonly.json
```

Create a new user `newuser` on MinIO use `mc admin user`.

```
mc admin user add myminio newuser newuser123
```

Once the user is successfully created you can now apply the `getonly` policy for this user.

```

```

### Create your feature branch

Before making code changes, make sure you create a separate branch for these changes

```
git checkout -b my-new-feature
```

### Test MinIO server changes

After your code changes, make sure

- To add test cases for the new code. If you have questions about how to do it, please ask on our [Slack](https://slack.min.io) channel.
- To run `make verifiers`

  - Bucket Policies
  - Bucket Tags
  - Bucket Object-Lock configurations (including retention and legal hold configuration)
  - Bucket Encryption configuration

> NOTE: Bucket versioning is automatically enabled for all new and existing buckets on all replicated sites.

The following Bucket features will **not be replicated**, is designed to differ between sites:

- Bucket notification configuration
- Bucket lifecycle (ILM) configuration

## Description


## Motivation and Context


## How to test this PR?


## Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Optimization (provides speedup with no functional changes)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)

## Checklist:

  --listen-peer-urls http://0.0.0.0:2380 \
  --initial-advertise-peer-urls http://0.0.0.0:2380 \
  --initial-cluster s1=http://0.0.0.0:2380 \
  --initial-cluster-token tkn \
  --initial-cluster-state new
```

You may also setup etcd with TLS following this documentation [here](https://coreos.com/etcd/docs/latest/op-guide/security.html)

### 3. Setup MinIO with etcd