Supported Cloud Providers
AWS
NOTE: For clusters with AWS make sure AWS CLI is installed and properly configured using an AWS account. This should set a configuration file at $HOME/.aws/config for your the AWS account. If you have multiple profiles configured on AWS, you can change the profile by setting export AWS_DEFAULT_PROFILE=<profile-name>
export AWS_DEFAULT_REGION=<aws-region>
This configuration will work for self managed AWS, ROSA and Rosa-HCP
GCP
NOTE: For clusters with GCP make sure GCP CLI is installed.
A google service account is required to give proper authentication to GCP for node actions. See here for how to create a service account.
NOTE: A user with ‘resourcemanager.projects.setIamPolicy’ permission is required to grant project-level permissions to the service account.
After creating the service account you will need to enable the account using the following: export GOOGLE_APPLICATION_CREDENTIALS="<serviceaccount.json>" or use gcloud init
In krkn-hub, you’ll need to both set the environemnt variable and also copy the file to the local container
-e GOOGLE_APPLICATION_CREDENTIALS=<container_creds_file>
Nees to match above file path
-v <local_gcp_creds_file>:<container_creds_file>:Z
Example:
podman run -e GOOGLE_APPLICATION_CREDENTIALS=/home/krkn/GCP_app.json -e DURATION=10 --net=host -v <kubeconfig>:/home/krkn/.kube/config:Z -v <local_gcp_creds_file>:/home/krkn/GCP_app.json:Z -d containers.krkn-chaos.dev/krkn-chaos/krkn-hub:...
Openstack
NOTE: For clusters with Openstack Cloud, ensure to create and source the OPENSTACK RC file to set the OPENSTACK environment variables from the server where Kraken runs.
Azure
NOTE: You will need to create a service principal and give it the correct access, see here for creating the service principal and setting the proper permissions.
To properly run the service principal requires “Azure Active Directory Graph/Application.ReadWrite.OwnedBy” api permission granted and “User Access Administrator”.
Before running you will need to set the following:
export AZURE_SUBSCRIPTION_ID=<subscription_id>export AZURE_TENANT_ID=<tenant_id>export AZURE_CLIENT_SECRET=<client secret>export AZURE_CLIENT_ID=<client id>
Note
This configuration will only work for self managed Azure, not ARO. ARO service puts a deny assignment in place over cluster managed resources, that only allows the ARO service itself to modify the VM resources. This is a capability unique to Azure and the structure of the service to prevent customers from hurting themselves. Refer to the links below for more documentation around this.
Alibaba
See the Installation guide to install alicloud cli.
export ALIBABA_ID=<access_key_id>export ALIBABA_SECRET=<access key secret>export ALIBABA_REGION_ID=<region id>
Refer to region and zone page to get the region id for the region you are running on.
Set cloud_type to either alibaba or alicloud in your node scenario yaml file.
VMware
Set the following environment variables
export VSPHERE_IP=<vSphere_client_IP_address>export VSPHERE_USERNAME=<vSphere_client_username>export VSPHERE_PASSWORD=<vSphere_client_password>
These are the credentials that you would normally use to access the vSphere client.
IBMCloud
If no api key is set up with proper VPC resource permissions, use the following to create:
- Access group
- Service ID with the following access:
- With policy VPC Infrastructure Services
- Resources = All
- Roles:
- Editor
- Administrator
- Operator
- Viewer
- API Key
Set the following environment variables
export IBMC_URL=https://<region>.iaas.cloud.ibm.com/v1export IBMC_APIKEY=<ibmcloud_api_key>
