Support for GKE Workload Identities for Okteto Self-Hosted

Feature Requests
1

I’d would like to be able to move away from using the key.json method that is described in the docs to provide cloud DNS and Cloud Storage access to my Okteto Self-Hosted instance.

2

@ramiro , my intuition is that you would want to use DEX Dex for something like this.

1 Like
3

Dex would be for client based authorization is my understanding. In the GKE context the IAP proxy might be better then DEX.

Here replacing the key.json with workload-id at the pod level would allow for the best practice method in service authorization to be used instead of mounting the key.json file directly to the pod. We currently have a security posture that requires us to utilize workload-id and kubernetes service account annotations rather than mounting the json token that would make this feature useful to us.

All this requires is the ability to annotate the built in serviceAccount that runs the okteto workloads working with Cloud DNS and Cloud Storage, as well as making sure the application code, traverses GCP’s default credential chain.

1 Like
4

Hi everyone,

I’m excited to announce that GCP Workload Identity and AWS IAM Roles for Service Accounts support for Okteto Enterprise Self Hosted is now available.

You’ll need version 0.12 of our Okteto Enterprise Helm chart for this feature to work.

Check out the following examples for enabling it in GCP and AWS:

GCP Workload Identity

Follow the Okteto Enterprise GKE guide, but omit the creation of “okteto-cloud-secret”.

Bind the GCP Service Account you just created with the K8S Service Account of cert-manager and Okteto Enterprise Registry. Replace the variables below with your own information.

gcloud iam service-accounts add-iam-policy-binding \
  ${GSA_NAME}@${GSA_PROJECT}.iam.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:${PROJECT_ID}.svc.id.goog[${RELEASE_NAMESPACE}/certmanager]"

gcloud iam service-accounts add-iam-policy-binding \
  ${GSA_NAME}@${GSA_PROJECT}.iam.gserviceaccount.com \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:${PROJECT_ID}.svc.id.goog[${RELEASE_NAMESPACE}/${RELEASE_NAME}-okteto-enterprise-registry]"

Merge or set the following YAML properties with your specific configuration. Replace the variables below with your own information.

cloud:
  provider:
    gcp:
      workloadIdentity:
        enabled: true

cert-manager:
  extraArgs: [--issuer-ambient-credentials=true]
  serviceAccount:
    annotations:
      iam.gke.io/gcp-service-account: GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com

registry:
  serviceAccount:
    create: true
    annotations:
      iam.gke.io/gcp-service-account: GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com

AWS

Follow the Okteto Enterprise EKS guide, but omit the creation of “okteto-cloud-secret” and the IAM user. Instead create an IAM policy with the actions specified in the guide.

Associate your AWS EKS cluster OIDC provider with your AWS IAM. Replace the variables below with your own information.

eksctl utils associate-iam-oidc-provider \
  --cluster $CLUSTER_NAME \
  --region $REGION \
  --approve

Create an AWS IAM Role for Service Account for cert-manager and Okteto Enterprise Registry. Replace the variables below with your own information.

eksctl create iamserviceaccount \
  --cluster $CLUSTER_NAME \
  --region $REGION \
  --name cert-manager \
  --namespace $RELEASE_NAMESPACE \
  --attach-policy-arn $POLICY_ARN \
  --role-name ${RELEASE_NAME}-cert-manager \
  --role-only \
  --approve

eksctl create iamserviceaccount \
  --cluster $CLUSTER_NAME \
  --region $REGION \
  --name ${RELEASE_NAME}-okteto-enterprise-registry \
  --namespace $RELEASE_NAMESPACE \
  --attach-policy-arn $POLICY_ARN \
  --role-name ${RELEASE_NAME}-okteto-enterprise-registry \
  --role-only \
  --approve

Merge or set the following YAML properties with your specific configuration. Replace the variables below with your own information.

cloud:
  provider:
    aws:
      iam:
        enabled: false

cert-manager:
  extraArgs: [--issuer-ambient-credentials=true]
  serviceAccount:
    annotations:
      eks.amazonaws.com/role-arn: 'arn:aws:iam::${AWS_ACCOUNT_ID}:role/${RELEASE_NAME}-cert-manager'

registry:
  serviceAccount:
    create: true
    annotations:
      eks.amazonaws.com/role-arn: 'arn:aws:iam::${AWS_ACCOUNT_ID}:role/${RELEASE_NAME}-okteto-enterprise-registry'
2 Likes
5

This is great. Are there any plans in to extend this functionality to the Okteto Installer as well ? Being able to provide the okteto installer Kubernetes ServiceAccount with a workload-id in GKE, would allow for tigther integrations into services like Artifact Registry.

6

Hi @apopp,

Right now, the installer pods launched by the same user will mount the same Kubernetes service account. Can you describe the use case (workflows, identity requirements, etc …) you have for Artifact Registry from Okteto installer pods? Do you see using it with other services (GCP Bigquery, Hashicorp Vault, AWS Sagemaker, etc …) in the future?

7

Howdy,

Our primary use case today would be to authenticate w. GCP for access to GAR for Helm charts. We make use of the helm upgrade --install command in the deploy: section of some of our okteto.yml manifests currently. We would like to install directly from the oci:// URL of the helm chart.

I don’t see any future use-cases in our org worth discussing atm.

8

@apopp would it work to define GAR as a private registry?

9

Howdy!
That will work for image pulls from GAR, but I am thinking about Helm charts. Could the same mechanism be used ?

This is somewhat related to another feature request OCI support in Okteto Enterprise built in registry

If I could just use Okteto’s built in registry for helm chart storage that would be great.