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

Full RawVM - Istio running on prem/on raw vms without k8s #541

Closed
ldemailly opened this issue Aug 7, 2017 · 4 comments
Closed

Full RawVM - Istio running on prem/on raw vms without k8s #541

ldemailly opened this issue Aug 7, 2017 · 4 comments

Comments

@ldemailly
Copy link
Contributor

This is to track the follow up work from 0.2's #357 where the full istio stack runs on raw vm and not just the sidecar

@ldemailly ldemailly added this to the Istio 0.3 milestone Aug 7, 2017
@ldemailly ldemailly added the Epic label Aug 7, 2017
@ldemailly
Copy link
Contributor Author

ldemailly commented Aug 7, 2017

@andraxylia
Copy link
Contributor

The work for 0.2 is done, can you update the epic with the issues/PRs, and either close it or move it to 0.3 if there are items left?

@ldemailly
Copy link
Contributor Author

it's already on 0.3 since it was created - again this is about no k8s at all

mandarjog pushed a commit to mandarjog/istio that referenced this issue Oct 30, 2017
* Updating pipeline version

bazel.updateBazelRc used to make the workspace dirty, which means that
all binary created per jenkins were marked as modified per build_stamp.sh

* Use same label date in docker image for both hub


Former-commit-id: 2cf9e62a91a0d22102c33ea70f78fcade6be4805
mandarjog pushed a commit that referenced this issue Oct 31, 2017
* Updating pipeline version

bazel.updateBazelRc used to make the workspace dirty, which means that
all binary created per jenkins were marked as modified per build_stamp.sh

* Use same label date in docker image for both hub


Former-commit-id: 7b726aa4897dc1beed8ae49bbe5628bb466d4223
mandarjog pushed a commit that referenced this issue Oct 31, 2017
* first pass https for egress external services

* switched to service.External() for external checks, go fmt's, added .External() to conversion tests

* unit test fixes for .golden files

* removed duplicate logic check

* formatting fixes

* created egress specific cluster ssl context
@ldemailly ldemailly removed this from the Istio 0.3 milestone Jan 30, 2018
@ldemailly ldemailly changed the title Full RawVM (0.3) - Istio running on prem/on raw vms without k8s Full RawVM - Istio running on prem/on raw vms without k8s Jan 30, 2018
@costinm
Copy link
Contributor

costinm commented Feb 22, 2018

It appears people in community managed to validate this, and I don't expect additional work on this area until after 1.0, it can be reopen if there is interest.

@costinm costinm closed this as completed Feb 22, 2018
rshriram pushed a commit to rshriram/istio that referenced this issue Jul 31, 2018
howardjohn pushed a commit to howardjohn/istio that referenced this issue Jan 12, 2020
* update for telemetryv2

* add gen

* add gen
howardjohn pushed a commit to howardjohn/istio that referenced this issue Jan 12, 2020
luksa added a commit to luksa/istio that referenced this issue Sep 15, 2022
…r IDs (istio#230) (istio#541)

Squashed commit, incorporates changes from:

  * MAISTRA-551 Run sidecar with a dynamically-determined runAsUser ID

  * MAISTRA-611 Partial injection of just the annotation and runAsUser id

  * MAISTRA-668 Fix expected output of webhook injection

  The sidecar injector now sets the securityContext.runAsUser field
  regardless if it is specified in the sidecar template or not. This is
  to allow the sidecar template to not include the field, which is
  required to ensure that istioctl kube-inject outputs manifests that
  pass the SCC admission controller (if the runAsUser is specified, the
  SCC controller will reject the pod, as the uid won't be in the proper
  range). The sidecar injector then injects the correct runAsUser id even
  if it isn't specified in the template.

  * MAISTRA-1751: Set securityContext.fsGroup to comply with restricted SCC (istio#256)

  This is a rewrite of 46f0f4a for the Maistra 2.1 / Istio 1.8 rebase.

  * MAISTRA-2452 Apply dynamically-determined user ID to the istio-validation init container

Co-authored-by: Marko Lukša <marko.luksa@gmail.com>
Co-authored-by: Brad Ison <bison@coreos.com>

Co-authored-by: Brian Avery <bavery@redhat.com>
Co-authored-by: Marko Lukša <marko.luksa@gmail.com>
Co-authored-by: Brad Ison <bison@coreos.com>
luksa added a commit to luksa/istio that referenced this issue Apr 11, 2024
…IDs (istio#689)

* [proxy-uid] MAISTRA-551: Run sidecars with dynamically-determined user IDs (istio#230) (istio#541)

Squashed commit, incorporates changes from:

  * MAISTRA-551 Run sidecar with a dynamically-determined runAsUser ID

  * MAISTRA-611 Partial injection of just the annotation and runAsUser id

  * MAISTRA-668 Fix expected output of webhook injection

  The sidecar injector now sets the securityContext.runAsUser field
  regardless if it is specified in the sidecar template or not. This is
  to allow the sidecar template to not include the field, which is
  required to ensure that istioctl kube-inject outputs manifests that
  pass the SCC admission controller (if the runAsUser is specified, the
  SCC controller will reject the pod, as the uid won't be in the proper
  range). The sidecar injector then injects the correct runAsUser id even
  if it isn't specified in the template.

  * MAISTRA-1751: Set securityContext.fsGroup to comply with restricted SCC (istio#256)

  This is a rewrite of 46f0f4a for the Maistra 2.1 / Istio 1.8 rebase.

  * MAISTRA-2452 Apply dynamically-determined user ID to the istio-validation init container

Co-authored-by: Marko Lukša <marko.luksa@gmail.com>
Co-authored-by: Brad Ison <bison@coreos.com>

Co-authored-by: Brian Avery <bavery@redhat.com>
Co-authored-by: Marko Lukša <marko.luksa@gmail.com>
Co-authored-by: Brad Ison <bison@coreos.com>

* [maistra-2.3] OSSM-1847 ensure ProxyUID and ProxyGID are initialized when using gat… (istio#618)

* OSSM-1847 ensure ProxyUID and ProxyGID are initialized when using gateway injection template

Signed-off-by: rcernich <rcernich@redhat.com>

* do not default ProxyUID and ProxyGID for gateways

Signed-off-by: rcernich <rcernich@redhat.com>

* initialize ProxyGID appropriately for gateway injection

Signed-off-by: rcernich <rcernich@redhat.com>

Signed-off-by: rcernich <rcernich@redhat.com>
Co-authored-by: rcernich <rcernich@redhat.com>

* fix(gen): runs make gen

* chore: combines cni plugins golden files gen into one invocation

Signed-off-by: rcernich <rcernich@redhat.com>
Co-authored-by: Jacek Ewertowski <jewertow@redhat.com>
Co-authored-by: Brian Avery <bavery@redhat.com>
Co-authored-by: Marko Lukša <marko.luksa@gmail.com>
Co-authored-by: Brad Ison <bison@coreos.com>
Co-authored-by: maistra-bot <57098434+maistra-bot@users.noreply.github.com>
Co-authored-by: rcernich <rcernich@redhat.com>

[maistra-2.4] OSSM-2324 Ensure ProxyUID and ProxyGID are never nil (istio#703)

* OSSM-2324 Ensure ProxyUID and ProxyGID are never nil

If they are nil, Helm renders them as "nil" (with quotes), which the YAML parser can't parse as a float.

* Remove redundant loop

Co-authored-by: Marko Lukša <marko.luksa@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants