You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/manual/plugins/kubernetes-plugins-overview.md
+48-14Lines changed: 48 additions & 14 deletions
Original file line number
Diff line number
Diff line change
@@ -1,12 +1,12 @@
1
-
# Kubernetes Plugins
1
+
# Kubernetes Integration Overview
2
2
:::enterprise
3
3
:::
4
4

5
5
6
6
Runbook Automation integrates with Kubernetes through a variety of plugins. By integrating Runbook Automation with Kubernetes, users can automate and provide self-service interfaces for operations in their Kubernetes Clusters.
7
7
8
-
:::warning Open Source Plugins
9
-
This document covers the plugins available in the commercial Runbook Automation products. For a list of Kubernetes plugins available for Rundeck Community (open-source), see documentation for the [**Open Source Kubernetes plugins**](/manual/plugins/kubernetes-open-source.md).
8
+
:::warning Commercial Plugins
9
+
This document covers the plugins available in the **commercial Runbook Automation products**. For a list of Kubernetes plugins available for **Rundeck Community (open-source)**, see documentation for the [**Open Source Kubernetes plugins**](/manual/plugins/kubernetes-open-source.md).
10
10
:::
11
11
12
12
## Adding Clusters & Authenticating with Kubernetes API
@@ -95,7 +95,12 @@ The Runner will now be able to authenticate with the Kubernetes API using the Se
95
95
The Cloud Provider Integration method can be used to dynamically retrieve all clusters from the cloud provider's API and add them as nodes to the inventory.
96
96
The cloud provider's API can _also_ be used to retrieve the necessary Kubernetes authentication to communicate with the clusters.
97
97
98
-
#### Cloud Provider for Cluster Discovery
98
+
:::tip Cloud Provider for Discovery and Pod Service Account for Authentication
99
+
It is possible to use the Cloud Provider Integration method for cluster discovery and the Pod-based Service Account method for authentication. This is useful when you want to dynamically discover clusters but have a 1:1 relationship between Runners and clusters or do not have the option to use the cloud provider for retrieving cluster credentials.
100
+
To take this approach, be sure to select the **Use Pod Service Account for Node Steps** when configuring the Node Source plugins.
101
+
:::
102
+
103
+
### Cloud Provider for Cluster Discovery
99
104
100
105
Use the Node Source plugins for the cloud provider to add the clusters to the Node Inventory:
101
106
@@ -105,7 +110,7 @@ Use the Node Source plugins for the cloud provider to add the clusters to the No
105
110
106
111
Note that a Runner does _not_ need to be installed to configure these Node Source plugins.
107
112
108
-
#### Cloud Provider for Kubernetes Authentication
113
+
### Cloud Provider for Kubernetes Authentication
109
114
110
115
Runbook Automation can use its integration with the public cloud providers to retrieve credentials to authenticate with the Kubernetes clusters.
111
116
@@ -117,15 +122,15 @@ With this approach, a single Runner is installed in either a VM or a container t
117
122
118
123

119
124
120
-
##### AWS EKS Authentication
125
+
### AWS EKS Authentication
121
126
122
127
To authenticate with EKS clusters using the AWS APIs:
123
128
124
129
1. Install a Runner in an EC2 instance or a container that has access to the EKS clusters.<br>
125
130
126
131
2. Assign permissions to the IAM role of this EC2 or container to allow the Runner to retrieve the necessary EKS cluster credentials:
127
132
- **`eks:DescribeCluster`**
128
-
3. Add the **EKS API** as an authentication mode and the IAM Role of the Runner's host (EC2 or container) to the target clusters:
133
+
3. Add the **EKS API** as an authentication mode and add the IAM Role of the Runner's host (EC2 or container) to the target clusters:
129
134
130
135
:::info Repeat for each target cluster
131
136
This process must be repeated for each target cluster so that the Runner can authenticate with each cluster.
@@ -154,18 +159,47 @@ To authenticate with EKS clusters using the AWS APIs:
154
159
```
155
160
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/EKS-my-cluster-self-managed-ng-1 --type STANDARD
156
161
```
162
+
Replace **`arn:aws:iam::111122223333:role/EKS-my-cluster-self-managed-ng-1`** with the IAM Role of the Runner's host.
157
163
:::tabs
164
+
165
+
Now when the Runner targets the EKS clusters using the Kubernetes node-step plugins, it will be able to authenticate with the clusters using credentials fetched from AWS.
158
166
159
-
##### Azure AKS Authentication
167
+
### Azure AKS Authentication
160
168
161
-
##### Google Cloud GKE Authentication
169
+
To authenticate with AKS clusters using the Azure APIs:
162
170
163
-
Follow the instructions in the **Node Source Plugins** linked in the prior sections to use the Cloud Provider Integration method.
171
+
1. Install a Runner in a VM or container that has a network path to the target AKS clusters.<br>
172
+
173
+
2. Follow the instructions in the [Azure Plugins Overview](/manual/plugins/azure-plugins-overview.md) to create a Service Principal and add the credentials for this Service Principal to Runbook Automation.
174
+
:::info Pre-existing Service Principal
175
+
If Runbook Automation has already been integrated with Azure, then you may not need to create a new Service Principal. Instead, add these permissions to the existing Service Principal.
176
+
:::
177
+
3. A assign permissions that allow this Service Principal to retrieve AKS cluster credentials:
- Azure provides pre-built roles that have this permission, such as **Azure Kubernetes Service Cluster User Role**.
180
+
:::tip Role Assignment Scope
181
+
The role assignment of these permissions can be assigned at the **Subscription**, **Resource Group** or even on an individual cluster basis.
182
+
Regardless of the chosen scope, navigate to the **Access Control (IAM)** section and add the role assignment.
183
+
:::
184
+
185
+
Now when the Runner targets the AKS clusters using the Kubernetes node-step plugins, it will be able to authenticate with the clusters using credentials fetched from Azure.
186
+
187
+
### Google Cloud GKE Authentication
188
+
189
+
To authenticate with GKE clusters using the Google Cloud APIs:
190
+
191
+
1. Install a Runner in a VM or container that has a network path to the target GKE clusters.<br>
192
+
193
+
2. Follow the instructions in the [Google Cloud Plugins Overview](/manual/plugins/gcp-plugins-overview.md) to create a Service Account and add the credentials for this Service Account to Runbook Automation.
194
+
:::info Pre-existing Service Account
195
+
If Runbook Automation has already been integrated with Google Cloud, then you may not need to create a new Service Account. Instead, add these permissions to the existing Service Account.
196
+
:::
197
+
3. Add a Role to the Service Account that has the permissions to retrieve the cluster credentials from the GKE service:
198
+
- **`container.clusters.get`**
199
+
- A predefined role, such as **Kubernetes Engine Developer**, can be used for this purpose.
200
+
201
+
Now when the Runner targets the GKE clusters using the Kubernetes node-step plugins, it will be able to authenticate with the clusters using credentials fetched from Google Cloud.
164
202
165
-
:::tip Cloud Provider for Discovery and Pod Service Account for Authentication
166
-
It is possible to use the Cloud Provider Integration method for cluster discovery and the Pod-based Service Account method for authentication. This is useful when you want to dynamically discover clusters but have a 1:1 relationship between Runners and clusters or do not have the option to use the cloud provider for retrieving cluster credentials.
167
-
To take this approach, be sure to select the **Use Pod Service Account for Node Steps** when configuring the Node Source plugins.
0 commit comments