-
Notifications
You must be signed in to change notification settings - Fork 8.1k
Create yaml files to enable Istio auth. #159
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
Conversation
Istio CA should not be installed by default. Created istio-cluster-ca.yaml and istio-namespace-ca.yaml for deploying the per-cluster and per-namespace CAs, so that users do not need to modify the files for different use cases.
Jenkins job istio/presubmit passed |
I think we are putting CA into one big YAML like istio-15-auth.yaml to allow one-command installation? @andraxylia |
@lookuptable |
You should also make changes to istio.VERSION and tests/updateVersion.sh, to allow changes to the hub/tag. It can be done is a separate PR. |
We decided for alpha on having a single yaml file, because currently auth cannot be enabled on top of an existing cluster, istio needs to be re-deployed. So you need to modify test/updateVersion.sh to generate an istio-auth-15.yaml, istio-auth-16.yaml, and istio-auth.yaml same as istio-auth-16.yaml. Then, in the install doc, we can add: If you want to deploy istio with authentication enabled, please run instead kubectl apply -f istio-auth.yaml. |
Jenkins job istio/presubmit passed |
kubernetes/istio-auth-15.yaml
Outdated
data: | ||
mesh: |- | ||
# Uncomment the following line to enable mutual TLS between proxies | ||
# authPolicy: MUTUAL_TLS |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be uncommented
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. Thanks.
valueFrom: | ||
fieldRef: | ||
apiVersion: v1 | ||
fieldPath: metadata.namespace |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Istio secret needs to be mounted onto Ingress
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
valueFrom: | ||
fieldRef: | ||
apiVersion: v1 | ||
fieldPath: metadata.namespace |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here: mount Istio secret onto Egress
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
kubernetes/istio-auth-15.yaml
Outdated
containers: | ||
- name: istio-ca | ||
image: docker.io/istio/istio-ca:2017-04-13-17.43.08 | ||
imagePullPolicy: IfNotPresent |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we sure we want to have cluster-wise CA in the demo? It'll make it hard to clean up
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean? I think kubectl delete -f istio-auth-15.yaml will do the clean up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It won't delete secrets that the CA creates in other namespaces.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to make it clear: I'm not against running cluster-wise CA as a basic principal. But for demo I think we should target for easy deploy and easy cleanup (deleting all resources created as part of running the demo).
I think we can run CA in which ever namespace the demo is deployed just as the app, manager and mixer. But have a separate doc talking about guideline/recommended way to deploy CA in really product environment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
kubectl delete -f istio-auth-15.yaml
will delete the namespace "istio-system", which will delete all secrets in that namespace, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope. Cluster-wise CA will issue certs to all namespaces. Say you already have namespace prod
and staging
. The command will only delete secrets in istio-system
namespace but leave secrets in prod and staging behind.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
About using the file in the demo: This file is not used for the demo, but the tutorial. istio-namespace-ca.yaml is used for the demo, which is exactly as you described.
About deleting the secrets in other namespaces: Yes, I think we need to have the caveats saying the certs/keys created for other namespaces won't be deleted. But as long as these secrets are not used, no one will care about it, right? Will there be potential troubles?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right. It seems the demo and tutorial are using the same setup now.
I will use per-namespace CA for the one-off setup file.
kubernetes/istio-auth-16.yaml
Outdated
apiVersion: extensions/v1beta1 | ||
metadata: | ||
name: istio-ca | ||
namespace: istio-system |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To get RBAC to work, CA needs to have its own service account and assign permissions to read service accounts and read+write secrets.
@@ -0,0 +1,342 @@ | |||
# GENERATED FILE. Use for Kubernetes 1.5 or earlier. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the difference between this file and istio-auth-15.yaml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No difference. It's a copy asked by @andraxylia, for default setup, I guess?
Jenkins job istio/presubmit passed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
@andraxylia can you please confirm that we want two files of the same content (istio.yaml
and istio-auth-15.yaml
)
Yes, we want to have something that simulates a symbolic link from istio.yaml to the default release file. One way to to achieve this in github is to have two files with the same content; content is generated anyway, so there is no double maintenance. |
Jenkins job istio/presubmit passed |
@andraxylia This PR is ready, can you please merge it if you don't have questions? Thanks! |
This PR adds the metrics aspect to mixer. This will allow the development of metrics backends that generate stats from Report() calls. Former-commit-id: bc509a6b46334449fdfc95d145b87e0aa3cc489c
Create yaml files to enable Istio auth. Former-commit-id: ba7d851
This PR adds the metrics aspect to mixer. This will allow the development of metrics backends that generate stats from Report() calls. Former-commit-id: bc06a2509980ecaaa80fe0c622aaf9105e35194f
Create yaml files to enable Istio auth. Former-commit-id: ba7d851
This is needed for prometheus to scrape it properly.
It appears anyone can approve patches if the CODEOWNERS file is misparsed.
…istio#159) This will resolve the errors caused by changes in the cache reflector code. Returning resourceVersion "0" will make sure we're getting the latest object versions from cache when re-List()ing. When Watch()ing, we're injecting the stored resourceVersions we observed during List(). Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
…anywhere (istio#159) Modified start-istio-proxy.sh to allow bootstrap files to be located anywhere. Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
* sync cni and master branches * WIP: initial daemonset work * start refactor, move net utils and start adding route table maintainence * label selector work * update api dep, move disabled selector to meshconfig, some more cleanup * sync cni and master branches * WIP: initial daemonset work * start refactor, move net utils and start adding route table maintainence * label selector work * update api dep, move disabled selector to meshconfig, some more cleanup * add uproxy rules to init container * WIP * finish networking setup * WIP * fix cni plugin * merge DSs and disable rp filter on iptables mode * remove ClusterFirstWithHostNet * fix render * cherry pick and merge ambient changes to init container * clean ups * working push, update readme * changes to informers * test fixes * readd cmddel func, test fix * make gen * remove script tests * remove test script * fix for CI job, update rules per Yuval's work * change constants to camelcase * add cleanup of ip rules to init * change rule numbers * change ipset comment to pod's UID, debug unit test for ipset * remove ipset unit test debug, add comment above masks on why they are included * add mutex locking * add dns capture, change ipset unit test for kernels that don't support comments * fixes to rules and comments to map where in the script the code originates * linting * more linting * test: need to label namespace for ambient mesh * Revert "test: need to label namespace for ambient mesh" This reverts commit 6f019b63f07b073bd7148b04a1e650cce58649fb. * We need host ip when removing the route of a pod * enabled ambientMode for ambient integration tests * fixes * fix readme * add check for ambient mesh in mesh config before using it * integ pod terminations were not being cleaned correctly * fix dns capture, and fix int test for ambient * linting * more linting * remove a todo * more linting * fix cleanup of uproxy rules on deletion of uproxy pod * move logs for uproxy to uproxy's init container * fix ambient.yaml log entries to be after flush * clean up the cleanup * reconcile namespaces after uproxy starts * more fixes * fix uproxyrunning check in plugin * lint changes * add more logging for CI * Also clean up mangle's uproxy-POSTROUTING chain. * rp_filter for istio links * add interim per-pod opt out, currently just ambient-type=pep * Update setup.sh for CNI and DNS capture (istio#191) * ignore ambient-type=none as well * uncomment sidecar in integ test * remove no longer needed comment Co-authored-by: Yuval Kohavi <yuval.kohavi@gmail.com> Co-authored-by: Greg Hanson <gregory.hanson@solo.io> Co-authored-by: Aaron Birkland <aaron.birkland@solo.io>
[jaeger] Fixing issue 158
…ter-merge_upstream_istio_master-6253864e Automator: merge upstream changes to openshift-service-mesh/istio@master
Remove Istio CA from the default installation dir.
Created istio-cluster-ca.yaml and istio-namespace-ca.yaml for deploying the
per-cluster and per-namespace CAs, so that users do not need to modify the files
for different use cases.