Are you looking to deploy NetApp® Trident™ on Google Kubernetes Engine (GKE) with Google Cloud NetApp Volumes (NetApp Volumes), but for security reasons you prefer not to deploy a Kubernetes secret for backend access? Meet Trident cloud identity, a deployment option that leverages GKE workload identity to maintain top-notch security and simplicity. By using Trident cloud identity, you can streamline the deployment of Trident, making the process straightforward and secure. This approach eliminates the need to manage Kubernetes secrets, offering a hassle-free experience, making deploying Trident on GKE smoother and more convenient.
NetApp Trident includes two authentication methods to create volumes on NetApp Volumes from a GKE cluster:
- Secret. This method requires downloading a key from a service account with the NetApp Volumes Admin predefined role (or a custom role) and copying credential information into both a backend custom resource and a Kubernetes secret. The secret and backend are then deployed in the same namespace as Trident and used by Trident to access NetApp Volumes.
- Cloud identity. This method directly links the Trident controller Kubernetes service account with a Google Cloud service account, allowing Trident to access NetApp Volumes by using permissions directly from that Google Cloud service account.
Cloud identity is considered the more secure method because it does not require deployment of credential secrets on Kubernetes. It uses Google Cloud Workload identity Federation, which allows you to use IAM policies to grant Kubernetes workloads access to certain Google Cloud APIs (including NetApp Volumes) without the need to generate and download keys, as shown below. Trident supports cloud identity with NetApp Volumes starting with version 24.10.
This blog contains step-by-step instructions for installing and using cloud identity with NetApp Trident and NetApp Volumes on a new GKE cluster. It also describes how to update a current GKE cluster for workload identity to use cloud identity with Trident.
If you prefer to watch this procedure with a new GKE cluster on video, look at Google Cloud NetApp Volumes: How to configure cloud identity with Trident and Google Kubernetes Engine.
Trident cloud identity on a new GKE cluster
This section gives step-by-step instructions on how to deploy a GKE cluster with the intent of using cloud identity. This article demonstrates use of the console, but the Google Cloud CLI could also be used to deploy the same resources. It also shows how to deploy Trident with cloud identity on the same cluster.
1. Create the GKE cluster.
Create a standard GKE cluster. During the cluster creation, be sure to turn on workload identity in the security section of the UI:
2. Create the service account in Google IAM and assign a role.
Create a new service account in your project. Assign the NetApp Volumes Admin Role or create a custom role for Trident. Go to IAM, Service Accounts Details, and click Create and Continue.
Add the NetApp Volumes Admin Role (or a custom role) to the service account and click Done.
The new service account should show up in Service Accounts:
You should also see it under IAM with the proper role assigned:
3. Install Trident version 24.10 or later.
You can use any method to install; this example uses the operator method. If Helm or tridentctl is used, make sure that the correct values are set, as identified in the following example.
After downloading Trident, create the tridentorchestrator CRD and deploy the Trident operator in the cluster as directed in the documentation.
Edit the TridentOrchestrator spec to add the cloudProvider and cloudIdentity lines, as shown in the following example. Change trident-gke-cloud-identity to the name of the new service account that you created in step 2.
kind: TridentOrchestrator
metadata:
name: trident
spec:
debug: true
namespace: trident
imagePullPolicy: IfNotPresent
windows: false
cloudProvider: "GCP"
cloudIdentity: 'iam.gke.io/gcp-service-account:trident-gke-cloud-identity@project.iam.gserviceaccount.com'
Apply the trident orchestrator to deploy Trident as shown in the documentation. Trident will come up and be running, as shown in the following example:
~$kubectl get pods -n trident
NAME READY STATUS RESTARTS AGE
trident-controller-5c5b8fd967-89wws 6/6 Running 0 89s
trident-node-linux-c4xbt 2/2 Running 0 88s
trident-node-linux-rndlk 2/2 Running 0 88s
trident-node-linux-zzrjm 2/2 Running 0 88s
trident-operator-6b69df767-wz54n 1/1 Running 0 2m34s
The Trident controller service account is now deployed in the trident namespace. This is the Trident service account that we will bind to the new Google Cloud service account that you created in step 2:
~$kubectl get sa -n trident
NAME SECRETS AGE
default 0 6m29s
trident-controller 0 4m51s
trident-node-linux 0 4m51s
trident-operator 0 5m40s
4. Bind the Google Cloud service account to the trident-controller service account.
Next, we bind the trident-controller Kubernetes service account to the Google Cloud service account, giving the trident-controller Kubernetes service account the same permissions as the Google Cloud service account. This can only be done by using the Google CLI or API. We will use the CLI.
Make sure that your workstation has gcloud CLI installed and has access to the appropriate project.
Give the trident-controller service account, located in the trident namespace, access to impersonate the IAM service account that you created in step 2. The command below gives the trident-controller service account access to the role workloadIdentity user in your GCP service account created in step 2. Be sure to change trident-gke-cloud-identity to the name of the service account that you created in step 2, and change cvs-pm-host-1p to your project name. If Trident was not installed in the trident namespace, you need to change trident also.
~$ gcloud iam service-accounts add-iam-policy-binding trident-gke-cloud-identity@cvs-pm-host-1p.iam.gserviceaccount.com –role=roles/iam.workloadIdentityUser –member="serviceAccount:cvs-pm-host-1p.svc.id.goog[trident/trident-controller]"
5. Annotate the trident-controller service account.
You need to annotate the trident-controller service account so that GKE sees the link between the two service accounts. If you brought up the cluster initially with workload identity enabled, this information might already be there:
~$kubectl annotate serviceaccount trident-controller --namespace trident iam.gke.io/gcp-service-account=trident-gke-cloud-identity@project.iam.gserviceaccount.com
serviceaccount/trident-controller annotated
Back on the Google Cloud console, you should also see that the trident-controller service account has permissions to use the Google Cloud service account. Go to Service Accounts and select the service account that you created in step 2. You should see something like the following example, replacing cvs-pm-host-1p with the name of your project:
6. Bring up the NetApp Volumes back end.
Make sure that a NetApp Volumes storage pool exists in your project with the applicable characteristics. In the following example, you need a storage pool in the us-central1 region with the flex service class. Be sure that you also have a Kubernetes storage class with the correct service level configured on the GKE cluster.
Create a Trident BackendConfiguration file for cloud identity. Apply the backend, as shown in the following example. Note that when using cloud identity, the API key section and a credentials secret are no longer needed. Be sure to replace the projectNumber, location, and labels with values for your environment.
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
name: tbc-gcnv
spec:
version: 1
storageDriverName: google-cloud-netapp-volumes
backendName: volumes-for-kubernetes
projectNumber: 'XXX'
location: us-central1
storage:
- labels:
performance: flex
serviceLevel: flex
Apply the backend manifest file:
~$ kubectl apply -f backend.yaml -n trident
The trident-controller service account uses the new Google Cloud service account permissions to authenticate. The backend should come up and be bound, as shown in the following example. You can now use Trident to create volumes.
~$kubectl get tbc tbc-gcnv -n trident
NAME BACKEND NAME BACKEND UUID PHASE STATUS
tbc-gcnv volumes-for-kubernetes e741fdbb-705e-494c-a573-50c488ce4721 Bound Success
Trident cloud identity on an existing GKE cluster
You can update a current GKE cluster to add cloud identity. However, if a cluster was created without workload identity enabled, you need to update the workload identity for the cluster and also update or add a new node pool with GKE metadata server enabled.
1. Update the cluster for workload identity.
Select the cluster to update, scroll down to the Security area, and enable workload identity:
2. Update the node pools.
To use cloud identity, you need to update each node pool.
Select the cluster you just enabled for workload identity and select the node pool within the cluster. You need to update all current node pools within the cluster, as shown in the following example:
Verify that GKE metadata server is disabled and then select Edit:
In the Security section, select Enable GKE MetaData Server and then click Save:
3. Install Trident and set up cloud identity.
Follow steps 2 through 6 in the "Trident Cloud Identity on a new GKE Cluster" section of this article.
Now what?
Now you can use Trident with Google Cloud NetApp Volumes even more securely than before! Try it out. Deploy a stateful application with a Persistent Volume Claim (PVC). Trident will create the Persistent Volume and the backend volume for you! Let us know how it goes, and which method you prefer.