Files
kubernetes/staging
Kubernetes Submit Queue 26caa84d09 Merge pull request #63445 from ericchiang/deprecate-git-repo-volume
Automatic merge from submit-queue (batch tested with PRs 63445, 63820). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.

core v1: deprecate the gitRepo volume type

gitRepo stopped accepting new features nearly 2 years ago https://github.com/kubernetes/kubernetes/issues/17676#issuecomment-228650586 and today this behavior can easily be achieved through an init container. The kubelet shelling out to git in the host namespace can also be a security issue on un-trusted repos, as was demonstrated by [CVE-2017-1000117](https://groups.google.com/forum/#!topic/kubernetes-announce/CTLXJ74cu8M). Our own documentation even alludes to this volume type being removed in the future:

> In the future, such volumes may be moved to an even more decoupled model, rather than extending the Kubernetes API for every such use case.

https://kubernetes.io/docs/concepts/storage/volumes/#gitrepo

Closes https://github.com/kubernetes/kubernetes/issues/60999

```release-note-action-required
The GitRepo volume type is deprecated. To provision a container with a git repo, mount an EmptyDir into an InitContainer that clones the repo using git, then mount the EmptyDir into the Pod's container.
```

/release-note-action-required

Instead of this:

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: server
spec:
  containers:
  - image: nginx
    name: nginx
    volumeMounts:
    - mountPath: /mypath
      name: git-volume
  volumes:
  - name: git-volume
    gitRepo:
      repository: "git@somewhere:me/my-git-repository.git"
      revision: "22f1d8406d464b0c0874075539c1f2e96c253775"
```

Do this:

```yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: git-clone
data:
  git-clone.sh: |
    #!/bin/sh -e
    git clone $1 $3
    cd $3
    git reset --hard $2
---
apiVersion: v1
kind: Pod
metadata:
  name: server
spec:
  initContainers:
  - name: git-clone
    image: alpine/git # Any image with git will do
    command:
    - /usr/local/git/git-clone.sh
    args:
    - "https://somewhere/me/my-git-repository.git"
    - "22f1d8406d464b0c0874075539c1f2e96c253775"
    - "/mypath"
    volumeMounts:
    - name: git-clone
      mountPath: /usr/local/git
    - name: git-repo
      mountPath: /mypath
  containers:
  - image: nginx
    name: nginx
    volumeMounts:
    - mountPath: /mypath
      name: git-volume
  volumes:
  - name: git-volume
    emptyDir: {}
  - name: git-clone
    configMap:
      name: git-clone
      defaultMode: 0755
```
2018-05-31 16:20:07 -07:00
..
2018-05-24 09:55:33 -07:00
2017-04-19 15:58:09 -04:00
2017-10-19 15:46:36 +01:00

External Repository Staging Area

This directory is the staging area for packages that have been split to their own repository. The content here will be periodically published to respective top-level k8s.io repositories.

Repositories currently staged here:

The code in the staging/ directory is authoritative, i.e. the only copy of the code. You can directly modify such code.

Using staged repositories from Kubernetes code

Kubernetes code uses the repositories in this directory via symlinks in the vendor/k8s.io directory into this staging area. For example, when Kubernetes code imports a package from the k8s.io/client-go repository, that import is resolved to staging/src/k8s.io/client-go relative to the project root:

// pkg/example/some_code.go
package example

import (
  "k8s.io/client-go/dynamic" // resolves to staging/src/k8s.io/client-go/dynamic
)

Once the change-over to external repositories is complete, these repositories will actually be vendored from k8s.io/<package-name>.