Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

kaniko builds should work with GKE workload identity #3468

Closed
jlewi opened this issue Dec 31, 2019 · 9 comments · Fixed by #5730
Closed

kaniko builds should work with GKE workload identity #3468

jlewi opened this issue Dec 31, 2019 · 9 comments · Fixed by #5730
Labels
area/build build/kaniko good first issue Good for newcomers help wanted We would love to have this done, but don't have the bandwidth, need help from contributors kind/feature-request priority/p3 agreed that this would be good to have, but no one is available at the moment.

Comments

@jlewi
Copy link
Contributor

jlewi commented Dec 31, 2019

Expected behavior

My expectation is that skaffold kaniko builds would work with GKE workload identity

Actual behavior

skaffold kaniko pods end up setting the environment variable GOOGLE_APPLICATION_CREDENTIALS.

As a result, kaniko pods will not try to use workload identity but instead look for the GCP secret to be provided in the location specified by the secret.

Information

  • Skaffold version: v1.1.1
  • Operating system: ...
  • Contents of skaffold.yaml:
apiVersion: skaffold/v2alpha1
kind: Config
metadata:
  name: label-microservice
build:
  artifacts:
  - image: gcr.io/issue-label-bot-dev/bot-worker
    # Set the context to the root directory. 
    # All paths in the Dockerfile should be relative to this one.
    context: ..
    # Automatically sync python files to the container. This should avoid
    # the need to rebuild and redeploy when the files change.
    # TODO(https://github.com/GoogleContainerTools/skaffold/issues/3448): We use manual sync
    # because inferred sync doesn't work
    #
    # This only works if we autorestart the program on changes.
    sync:
        manual:
        - src: 'py/code_intelligence/*.py'
          dest: '/'
        - src: 'py/label_microservice/*.py'
          dest: '/'
    kaniko:
      dockerfile: Label_Microservice/deployment/Dockerfile.worker
      buildContext:
        gcsBucket: issue-label-bot-dev_skaffold-kaniko
      cache: {}
  cluster:    
    # TODO(jlewi): This should be changed for each developer; or maybe we should create a reusable one?
    namespace: kaniko
    resources:
      requests:
        cpu: 8
        memory: 16Gi

deploy:
  kustomize:
    path: deployment/overlays/dev

Steps to reproduce the behavior

  1. a clonable repository with the sample skaffold project
  2. skaffold <command>
  3. ...
@tejal29
Copy link
Contributor

tejal29 commented Jan 14, 2020

@jlewi Thanks for opening this issue. At this time, we don't have a clear understanding of workload identity. I will look into what (if any) pod config is required for kaniko pod and then follow up here in skaffold.

Thanks

@jlewi
Copy link
Contributor Author

jlewi commented Jan 17, 2020

@tejal29 Thanks. If you are using Google Cloud Client libraries to get credentials you shouldn't need to do anything. The client libraries should attempt to contact the metadata server to get credentials if GOOGLE_APPLICATION_CREDENTIALS isn't set.

@balopat balopat added the good first issue Good for newcomers label Jan 30, 2020
@balopat
Copy link
Contributor

balopat commented Jan 30, 2020

This should be relatively easy to implement.
We can add a skipGcpCredentials flag to build.artifact.kaniko.

@tstromberg
Copy link
Contributor

@balopat - seems reasonable. Alternatively, if we just remove GOOGLE_APPLICATION_CREDENTIALS from kaniko, shouldn't it do the right thing with newer libraries?

@chanseokoh
Copy link
Member

I think you still want GOOGLE_APPLICATION_CREDENTIALS for a way to supply GCR credentials on a non-GKE cluster?

And does kaniko use Google Cloud Client libraries to get credentials?

@nkubala nkubala added help wanted We would love to have this done, but don't have the bandwidth, need help from contributors priority/p3 agreed that this would be good to have, but no one is available at the moment. and removed priority/p2 May take a couple of releases labels Jul 30, 2020
@nkubala
Copy link
Contributor

nkubala commented Jul 30, 2020

cc @tejal29 do you know? also, is anyone interested in fixing this one?

@jlewi
Copy link
Contributor Author

jlewi commented Aug 4, 2020

Workload identity also depends on being able to set the K8s service account in order to control the GCP identity that is used.

On GKE/GCP it is increasingly common to disallow exporting of service account keys. So this is becoming a blocker.

@jlewi
Copy link
Contributor Author

jlewi commented Aug 4, 2020

Per: GoogleContainerTools/kaniko#968 kaniko works just fine with workload identity. So the issue is just properly configuring the kaniko pod so that WI works. Specifically

  1. Don't set GOOGLE_APPLICATION_CREDENTIALS
  2. Make the K8s service account configurable

@jlewi
Copy link
Contributor Author

jlewi commented Aug 24, 2020

I just tried using the latest v2beta6 spec (https://skaffold.dev/docs/references/yaml/)
And skaffold 1.13.2

It looks like we can set the K8s service account on the pod.

To disable GOOGLE_APPLICATION_CREDENTIALS; it looks like we could just add an if statement here

env := []v1.EnvVar{{

to not set if pullSecretPath is the empty string.

Likewise I think we could add an if statement to addSecretVolume to not add the secret volume if the secret is the empty string.

func addSecretVolume(pod *v1.Pod, name, mountPath, secretName string) {

It looks like there might a new code path related to using Tekton

if artifact.KanikoArtifact != nil {

  • It looks like the Kaniko secret is currently hard coded in that case.

@nkubala nkubala added this to the Icebox [P2+] milestone Sep 1, 2020
@briandealwis briandealwis modified the milestones: Icebox [P2+], v1.16.0 Oct 5, 2020
@nkubala nkubala modified the milestones: v1.16.0, v1.17.0 Nov 9, 2020
@briandealwis briandealwis modified the milestones: v1.17.0, v1.18.0 Nov 25, 2020
@briandealwis briandealwis modified the milestones: v1.18.0, v1.19.0 Jan 25, 2021
@nkubala nkubala removed this from the v1.20.0-candidate milestone Feb 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/build build/kaniko good first issue Good for newcomers help wanted We would love to have this done, but don't have the bandwidth, need help from contributors kind/feature-request priority/p3 agreed that this would be good to have, but no one is available at the moment.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants