diff --git a/site/docs/master/aws-config.md b/site/docs/master/aws-config.md index ecd1e339d..ab1ca9dfb 100644 --- a/site/docs/master/aws-config.md +++ b/site/docs/master/aws-config.md @@ -17,13 +17,13 @@ If you do not have the `aws` CLI locally installed, follow the [user guide][5] t Velero. The tarballs for each release contain the `velero` command-line client. The code in the master branch of the Velero repository is under active development and is not guaranteed to be stable!_ -1. Extract the tarball: - ```bash - tar -xvf .tar.gz -C /dir/to/extract/to - ``` +2. Extract the tarball: +```bash +tar -xvf .tar.gz -C /dir/to/extract/to +``` We'll refer to the directory you extracted to as the "Velero directory" in subsequent steps. -1. Move the `velero` binary from the Velero directory to somewhere in your PATH. +3. Move the `velero` binary from the Velero directory to somewhere in your PATH. ## Create S3 bucket @@ -50,91 +50,87 @@ aws s3api create-bucket \ For more information, see [the AWS documentation on IAM users][14]. 1. Create the IAM user: +```bash +aws iam create-user --user-name velero +``` - ```bash - aws iam create-user --user-name velero - ``` - - > If you'll be using Velero to backup multiple clusters with multiple S3 buckets, it may be desirable to create a unique username per cluster rather than the default `velero`. + If you'll be using Velero to backup multiple clusters with multiple S3 buckets, it may be desirable to create a unique username per cluster rather than the default `velero`. 2. Attach policies to give `velero` the necessary permissions: - - ```bash - cat > velero-policy.json < velero-policy.json <, - "AccessKeyId": - } - } - ``` +```json +{ + "AccessKey": { + "UserName": "velero", + "Status": "Active", + "CreateDate": "2017-07-31T22:24:41.576Z", + "SecretAccessKey": , + "AccessKeyId": + } +} +``` 4. Create a Velero-specific credentials file (`credentials-velero`) in your local directory: - - ``` - [default] - aws_access_key_id= - aws_secret_access_key= - ``` +```bash +[default] +aws_access_key_id= +aws_secret_access_key= +``` where the access key id and secret are the values returned from the `create-access-key` request. @@ -165,26 +161,26 @@ For more complex installation needs, use either the Helm chart, or add `--dry-ru * If you have multiple clusters and you want to support migration of resources between them, you can use `kubectl edit deploy/velero -n velero` to edit your deployment: * Add the environment variable `AWS_CLUSTER_NAME` under `spec.template.spec.env`, with the current cluster's name. When restoring backup, it will make Velero (and cluster it's running on) claim ownership of AWS volumes created from snapshots taken on different cluster. - The best way to get the current cluster's name is to either check it with used deployment tool or to read it directly from the EC2 instances tags. - + The best way to get the current cluster's name is to either check it with used deployment tool or to read it directly from the EC2 instances tags. + The following listing shows how to get the cluster's nodes EC2 Tags. First, get the nodes external IDs (EC2 IDs): - ```bash - kubectl get nodes -o jsonpath='{.items[*].spec.externalID}' - ``` - + ```bash + kubectl get nodes -o jsonpath='{.items[*].spec.externalID}' + ``` + Copy one of the returned IDs `` and use it with the `aws` CLI tool to search for one of the following: * The `kubernetes.io/cluster/` tag of the value `owned`. The `` is then your cluster's name: - ```bash - aws ec2 describe-tags --filters "Name=resource-id,Values=" "Name=value,Values=owned" - ``` - + ```bash + aws ec2 describe-tags --filters "Name=resource-id,Values=" "Name=value,Values=owned" + ``` + * If the first output returns nothing, then check for the legacy Tag `KubernetesCluster` of the value ``: - ```bash - aws ec2 describe-tags --filters "Name=resource-id,Values=" "Name=key,Values=KubernetesCluster" + ```bash + aws ec2 describe-tags --filters "Name=resource-id,Values=" "Name=key,Values=KubernetesCluster" ``` ## ALTERNATIVE: Setup permissions using kube2iam @@ -196,113 +192,109 @@ For more complex installation needs, use either the Helm chart, or add `--dry-ru It can be set up for Velero by creating a role that will have required permissions, and later by adding the permissions annotation on the velero deployment to define which role it should use internally. 1. Create a Trust Policy document to allow the role being used for EC2 management & assume kube2iam role: - - ```bash - cat > velero-trust-policy.json < velero-trust-policy.json <:role/" - }, - "Action": "sts:AssumeRole" - } - ] - } - EOF - ``` + "Action": "sts:AssumeRole" + }, + { + "Effect": "Allow", + "Principal": { + "AWS": "arn:aws:iam:::role/" + }, + "Action": "sts:AssumeRole" + } + ] +} +EOF +``` 2. Create the IAM role: - - ```bash - aws iam create-role --role-name velero --assume-role-policy-document file://./velero-trust-policy.json - ``` +```bash +aws iam create-role --role-name velero --assume-role-policy-document file://./velero-trust-policy.json +``` 3. Attach policies to give `velero` the necessary permissions: - - ```bash - BUCKET= - cat > velero-policy.json < +cat > velero-policy.json <:role/ - ... - ``` +``` +--- +apiVersion: apps/v1beta1 +kind: Deployment +metadata: + namespace: velero + name: velero +spec: + replicas: 1 + template: + metadata: + labels: + component: velero + annotations: + iam.amazonaws.com/role: arn:aws:iam:::role/ +``` ## Installing the nginx example (optional) If you run the nginx example, in file `examples/nginx-app/with-pv.yaml`: - * Replace `` with `gp2`. This is AWS's default `StorageClass` name. +Replace `` with `gp2`. This is AWS's default `StorageClass` name. [0]: namespace.md [5]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html diff --git a/site/docs/v1.0.0/aws-config.md b/site/docs/v1.0.0/aws-config.md index ecd1e339d..ab1ca9dfb 100644 --- a/site/docs/v1.0.0/aws-config.md +++ b/site/docs/v1.0.0/aws-config.md @@ -17,13 +17,13 @@ If you do not have the `aws` CLI locally installed, follow the [user guide][5] t Velero. The tarballs for each release contain the `velero` command-line client. The code in the master branch of the Velero repository is under active development and is not guaranteed to be stable!_ -1. Extract the tarball: - ```bash - tar -xvf .tar.gz -C /dir/to/extract/to - ``` +2. Extract the tarball: +```bash +tar -xvf .tar.gz -C /dir/to/extract/to +``` We'll refer to the directory you extracted to as the "Velero directory" in subsequent steps. -1. Move the `velero` binary from the Velero directory to somewhere in your PATH. +3. Move the `velero` binary from the Velero directory to somewhere in your PATH. ## Create S3 bucket @@ -50,91 +50,87 @@ aws s3api create-bucket \ For more information, see [the AWS documentation on IAM users][14]. 1. Create the IAM user: +```bash +aws iam create-user --user-name velero +``` - ```bash - aws iam create-user --user-name velero - ``` - - > If you'll be using Velero to backup multiple clusters with multiple S3 buckets, it may be desirable to create a unique username per cluster rather than the default `velero`. + If you'll be using Velero to backup multiple clusters with multiple S3 buckets, it may be desirable to create a unique username per cluster rather than the default `velero`. 2. Attach policies to give `velero` the necessary permissions: - - ```bash - cat > velero-policy.json < velero-policy.json <, - "AccessKeyId": - } - } - ``` +```json +{ + "AccessKey": { + "UserName": "velero", + "Status": "Active", + "CreateDate": "2017-07-31T22:24:41.576Z", + "SecretAccessKey": , + "AccessKeyId": + } +} +``` 4. Create a Velero-specific credentials file (`credentials-velero`) in your local directory: - - ``` - [default] - aws_access_key_id= - aws_secret_access_key= - ``` +```bash +[default] +aws_access_key_id= +aws_secret_access_key= +``` where the access key id and secret are the values returned from the `create-access-key` request. @@ -165,26 +161,26 @@ For more complex installation needs, use either the Helm chart, or add `--dry-ru * If you have multiple clusters and you want to support migration of resources between them, you can use `kubectl edit deploy/velero -n velero` to edit your deployment: * Add the environment variable `AWS_CLUSTER_NAME` under `spec.template.spec.env`, with the current cluster's name. When restoring backup, it will make Velero (and cluster it's running on) claim ownership of AWS volumes created from snapshots taken on different cluster. - The best way to get the current cluster's name is to either check it with used deployment tool or to read it directly from the EC2 instances tags. - + The best way to get the current cluster's name is to either check it with used deployment tool or to read it directly from the EC2 instances tags. + The following listing shows how to get the cluster's nodes EC2 Tags. First, get the nodes external IDs (EC2 IDs): - ```bash - kubectl get nodes -o jsonpath='{.items[*].spec.externalID}' - ``` - + ```bash + kubectl get nodes -o jsonpath='{.items[*].spec.externalID}' + ``` + Copy one of the returned IDs `` and use it with the `aws` CLI tool to search for one of the following: * The `kubernetes.io/cluster/` tag of the value `owned`. The `` is then your cluster's name: - ```bash - aws ec2 describe-tags --filters "Name=resource-id,Values=" "Name=value,Values=owned" - ``` - + ```bash + aws ec2 describe-tags --filters "Name=resource-id,Values=" "Name=value,Values=owned" + ``` + * If the first output returns nothing, then check for the legacy Tag `KubernetesCluster` of the value ``: - ```bash - aws ec2 describe-tags --filters "Name=resource-id,Values=" "Name=key,Values=KubernetesCluster" + ```bash + aws ec2 describe-tags --filters "Name=resource-id,Values=" "Name=key,Values=KubernetesCluster" ``` ## ALTERNATIVE: Setup permissions using kube2iam @@ -196,113 +192,109 @@ For more complex installation needs, use either the Helm chart, or add `--dry-ru It can be set up for Velero by creating a role that will have required permissions, and later by adding the permissions annotation on the velero deployment to define which role it should use internally. 1. Create a Trust Policy document to allow the role being used for EC2 management & assume kube2iam role: - - ```bash - cat > velero-trust-policy.json < velero-trust-policy.json <:role/" - }, - "Action": "sts:AssumeRole" - } - ] - } - EOF - ``` + "Action": "sts:AssumeRole" + }, + { + "Effect": "Allow", + "Principal": { + "AWS": "arn:aws:iam:::role/" + }, + "Action": "sts:AssumeRole" + } + ] +} +EOF +``` 2. Create the IAM role: - - ```bash - aws iam create-role --role-name velero --assume-role-policy-document file://./velero-trust-policy.json - ``` +```bash +aws iam create-role --role-name velero --assume-role-policy-document file://./velero-trust-policy.json +``` 3. Attach policies to give `velero` the necessary permissions: - - ```bash - BUCKET= - cat > velero-policy.json < +cat > velero-policy.json <:role/ - ... - ``` +``` +--- +apiVersion: apps/v1beta1 +kind: Deployment +metadata: + namespace: velero + name: velero +spec: + replicas: 1 + template: + metadata: + labels: + component: velero + annotations: + iam.amazonaws.com/role: arn:aws:iam:::role/ +``` ## Installing the nginx example (optional) If you run the nginx example, in file `examples/nginx-app/with-pv.yaml`: - * Replace `` with `gp2`. This is AWS's default `StorageClass` name. +Replace `` with `gp2`. This is AWS's default `StorageClass` name. [0]: namespace.md [5]: https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-welcome.html