istio
/
istio.io
mirror of https://github.com/istio/istio.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
Source for the istio.io site
3,757 Commits 102 Branches 0 Tags 968 MiB
HTML 99%
Shell 1%
Go to file
Vadim Eisenberg dbb23e1fdb Blog post about using Istio multi-mesh for isolation and boundary protection (#4776) 
* initial version

* add structure and certificate generation

* remove redundant article

* create the reviews service and later delete it

required for pods to start

* kubernetes -> kubectl

* complete creating the egress gateway section

* add deployment of an ingress gateway

* use LoadBalancer type for the private ingress gateway

* expand the cleanup section

* add "Expose reviews v2" section

* use hostnames in CN so it can be verified by curl

* use a single slash in HTTPRewrite uri field

* fix the virtual service and the curl call

* add a troubleshooting section

* use port 80 in the egress gateway's deployment

* implement the consume section for reviews v2

* expand the troubleshooting section

* split a virtual service, use port 443

* unite two virtual services for reviews

* add namespace to the gateway reference

* complete the cleaning instructions

* fix prefix match and rewrite in consuming reviews v2

* rename the gateway, destination rule, rewrite authority in ingress cluster2

* split the virtual service in cluster1 into two parts

* set access log format to print both the path and the rewritten path

* extend the cleanup section

* add load balancing between the local and remote versions of reviews

* remove usi

* change consume/expose details to ratings

* add diagrams

* canary release the remote version

* fix the subtitle and the publish date

* add subset v1 to the routing to the local version

* use local name (reviews) for a virtual service in the default namespace

* add the 'Deploy reviews v2 locally and retire reviews v1' section

* a Gateway -> an ingress Gateway

* virtualservice myreviews-bookinfo-v2 -> virtualservice privately-exposed-services

* add the "Expose ratings and reviews v3" section

* add printing response code to curl commands

* add a step to delete the consumption of the remote service from `cluster2`

* add a section "Consume ratings and reviews v3"

* add a section about Istio RBAC

* rewrite certificate creation - add spiffe SAN

* add a section about RBAC on ingress gateway

* remove redundant quote

* add extended key usage and critical to subjectAltName

* add generation of certificate and key for cluster3

* rewrite ingress RBAC in cluster2 to use EnvoyFilter for RBAC

Istio RBAC currently does not support getting principal for
MUTUAL TLS, only for ISTIO_MUTUAL

* fix MeshFederation5, the local version of reviews must be v2

* fix a typo

* add the "Cancel exposure of ratings" section

* add checking Istio configuration artifacts

* rewrite the introduction, add requirements and the proposed implementation section

* to base implementation -> to base the implementation

* split a long line

* web page -> webpage

* fix indentation

* of deploying -> after deploying

* add an explanation about openssl

* extend the explanation about `cluster3`

* add an explanation about deploying gateways

* create the certificates -> create the certificates and keys

* remove "the" from "to generate the certificates and the keys"

* minor changes in gateway deployment

* mount volumes from secrets -> mount secrets as data volumes

* add explanation about private gateways

* cluster1 and cluster2 -> both clusters

* add an explanation about exposure/consumption

* add an explanation about c1,c2,c3.example.com hostnames

* real URL -> existing hostname

* port 80 -> port 443 (the egress gateway)

* remove the non-mTLS options

* VirtualService -> virtual service

* fix indentation

* remove back ticks from reviews v1 and v2

* in remote cluster -> is in remote cluster

* add explanation about expose-nothing behavior by default

* add a separating empty line

* port 80 -> port 443

* VirtualService -> virtual service, part 2

* your Kubernetes cluster -> your second cluster

* add "in case you have a load balancer"

* add "in case you have a load balancer... otherwise..."

* fix the pod of reviews-v2 in the first cluster

mention the new pod

* web page -> webpage

* cluster1 -> the first cluster

* make multiple tests a sublist

* rewrite the sentence "Let's change the RBAC policy"

remove let's
remote passive voice

* rewrite the series of the tests to check RBAC

* issues requests -> sends requests

* Let's consider -> consider

* split a long line

* add "locally" to has access to ratings

* the ratings -> ratings

* use first/second cluster instead of cluster1/cluster2 in headings

* add a subsection to remove certificate and key files

* extend the sentence about role binding

* extend the sentence about enabling Istio RBAC on bookinfo

* rewrite the sentence about accessing the webpage of the bookinfo app

* add an explanation about the EnvoyFilter

* other 50% -> the other 50%

* 50% of time -> 50% of the time

* at cluster -> in cluster

* rewrite the sentence about cleaning Istio RBAC

* add summary

* in the subtitle: traffic control -> strict access control

* for the many different reasons -> for different reasons

* special certificates -> dedicated certificates, add dots

* add a sentence about defense in depth and PCI compliance

* fix typos

* through their gateways -> through corresponding gateways

* _v1_ -> `v1`

* ad-hoc -> ad hoc

* put EnvoyFilter and the name of the Envoy's filter in backticks

* instructions for NodePort Ingress -> instructions for using node port for ingress

* add "hoc" to .spelling, for "ad hoc" expression

* fix a link

* remove unneeded single bullet

* fix a link for Defense-in-depth

* rewrite the list of reasons for split applications between multiple clusters

* add a clause about boundary protection

* expand on non-uniform naming

* rewrite the bullet about boundary protection

* expand on the lack of common trust

* fix division into paragraphs in the introduction

* different as -> different than

* in different namespaces in a cluster -> in the clusters

* to the ratings -> to the ratings service

* rewrite the explanation about DNS and routing

* add a comma after "destined to ratings"

* split a long line

* replace PCI DSS with boundary protection

* remove an unneeded empty line

* split long lines in the summary

* simplify the sentence in the summary about explicit exposure of the clusters

* put "paired" in italics

* split a long line

* change the publish date to 12-th of August

* split a long line

* add the "Isolation of system components and boundary protection" subsection

* rephrase a sentence to remove passive voice

* add cyber and subnetworks to .spelling

used by NIST Special Publication 800-53, Revision 4, Security and Privacy
Controls for Federal Information Systems and Organizations:

This type of enhanced protection limits the potential harm from cyber attacks...

... routers, gateways, and firewalls separating system components into physically separate networks or
subnetworks

* rephrase and reformat the section about boundary protection and isolation

* rewrite the section about isolation and boundary protection

* Kubernetes community -> the Kubernetes community

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* three patterns -> three documented patterns

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* three patterns differ -> the differences between the patterns

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* add "where none of the multi cluster patterns apply" to "there are cases when you want to"

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* didn't establish -> have not established

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* rewrite the sentence about the best solution and the goal

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* Payment Card Industry Data Security Standard -> the ..

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* move "in my opinion" to the beginning of the sentence

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* move "in my opinion" to the beginning of the sentence, part 2

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* Add "the" to PCI DSS

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* add "approach" after "the proposed mesh federation"

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* add "the" before NIST

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* uniform identical naming -> uniform naming

* common indentity and common trust -> common identity and trust

* mesh-federation -> isolated-clusters

* rewrite the blog post, removing mesh federation and multicluster mesh mentioning

* add the "Testing the certificates in the chain of calls" section

* Revert "add the "Testing the certificates in the chain of calls" section"

This reverts commit 6ada5903e5.

* remove redundant parenthesis around the first link to PCI DSS

* fix a typo (though -> through)

* remove the last '/' which seems to confuse lint

* remove namespace qualifier for gateways in virtual services

since the virtual services are in the same namespace

* extend the explanation about RBAC

* try another link for gdpr

* add `&nbsp;` to try to make lint happy

* Revert "add `&nbsp;` to try to make lint happy"

This reverts commit 552806883f.

* rewrite the list of standards as a table, add links to the paragraph below

* put full service name in backticks

* fix a typo (localtion -> location)

* fix the level of the first section

* rename the ca-example-com-certs secrets into c1/c2-trusted-certs secrets

to enable running commands in a single cluster

* use kubectl apply to create a namespace in case it already exists

for the single cluster scenario

* add deleting of the ratings service in the first cluster

during the initial setting

* change the error in case ratings is not found

* remove istio-private-gateways from the list of RBAC-included namespaces

* add '--ignore-not-found=true' to the kubectl delete commands

to support the case of a single cluster

* credit card -> payment card

* add running the blog post in a single cluster

* add unsetting environment variables to the cleanup section

* fix internal links

* The approach I propose - The approach I use

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* features of the proposed approach -> features of the approach

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* I propose -> I use

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* I propose to base connecting clusters on  -> I connect clusters based on

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* add "some of the process could clearly benefit from automation..."

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* similar the pattern -> similar to the pattern

* the proposed implementation -> the implementation pattern

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* added a comment that my approach is different from multicluster meshes

* fix a link

* add a multi-mesh section to examples

* move the blog post about cluster isolation to examples

* rewrite the blog post as example

* add a missing period in the description

* Revert "add a missing period in the description"

This reverts commit 14f656280f.

* Revert "rewrite the blog post as example"

This reverts commit 875a4f55f0.

* Revert "move the blog post about cluster isolation to examples"

This reverts commit 17b20a1cb5.

* Revert "add a multi-mesh section to examples"

This reverts commit 9d9365eee7.

* rewrite the blog post to not contain the same service (reviews) in two meshes

per comments of Sven Mawson
using ratings and httpbin to show exposure of two services

* fix the link to Envoy's RBAC filter

* fix an internal link

* fix spelling

* remove redundant empty line

* remove "no common trust" from the single cluster

* initial version after moving the example to istio-ecosystem

* fix list formatting

* additional touches

replace cluster with mesh everywhere
add monitoring at the boundary

* describe -> outline, report

* put all mesh-federation and multi-mesh instances into the glossary markup

* update the publish date

* call "service location transparency" an optional feature

* rewrote "Service location transparency is important" to "Service location transparency is useful in the cases when you want"

* the istio-ecosystem repository -> Istio ecosystem

* rewrite subtitle

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* Rewrite the title

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* rewrite the sentence about isolation

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* rewrite the sentence about separate service meshes on separate networks

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* Remove "Istio to connect applications in the meshes with different compliance requirements"

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* remove the glossary item from mesh federation and add "support and automation work under way"

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* remove glossary reference

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* remove glossary reference, 2

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* add comparison with multi-cluster (single mesh)

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* remove glossary reference, 3

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* remove glossary reference, 4

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* remove glossary reference, 5

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* remove glossary reference, 5

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* remove glossary reference, 6

Co-Authored-By: Frank Budinsky <frankb@ca.ibm.com>

* remove glossary reference, 7

* report -> touch on

* update the date of the blog
 		2019-10-02 06:40:25 -07:00
.github Update reference docs. (#4552) 2019-06-24 17:02:04 -07:00
archetypes Introduce top-level News section. (#5060) 2019-09-27 07:09:58 -07:00
assets/inline_images Script cleanup (#3372) 2019-02-25 07:19:06 -08:00
common Update common files. (#5081) 2019-09-29 10:31:30 -07:00
content Blog post about using Istio multi-mesh for isolation and boundary protection (#4776) 2019-10-02 06:40:25 -07:00
data Update reference docs. (#4979) 2019-09-12 13:23:39 -07:00
i18n Translate i18n for zh (#4817) 2019-09-18 09:32:02 -07:00
layouts Add istio.io/release-builder vanity url (#5072) 2019-09-27 13:45:27 -07:00
scripts add newrelic-istio-adapter repo to adapter docs (#5053) 2019-09-25 08:51:35 -07:00
src Introduce top-level News section. (#5060) 2019-09-27 07:09:58 -07:00
static Add istio.io/release-builder vanity url (#5072) 2019-09-27 13:45:27 -07:00
test Merge from release-1.1 branch (#4012) 2019-04-20 08:16:09 -07:00
.gitattributes Update common files. (#5052) 2019-09-25 06:56:54 -07:00
.gitignore Stop checking in the "generated" directory. (#4365) 2019-06-12 19:48:49 +00:00
.spelling Blog post about using Istio multi-mesh for isolation and boundary protection (#4776) 2019-10-02 06:40:25 -07:00
BUGS-AND-FEATURE-REQUESTS.md Update common files. (#4770) 2019-08-06 14:03:36 -07:00
CODEOWNERS Update CODEOWNERS. 2019-08-31 09:34:15 -07:00
CONTRIBUTING.md Import common files into this repo. (#4246) 2019-05-31 05:01:37 -07:00
LICENSE Update common files. (#4770) 2019-08-06 14:03:36 -07:00
Makefile Update common files. (#5081) 2019-09-29 10:31:30 -07:00
Makefile.core.mk Another attempt at fixing archive builds. 2019-09-12 12:24:48 -07:00
Makefile.overrides.mk Set BUILD_WITH_CONTAINER=1 by default. 2019-08-18 07:02:05 -07:00
README.md Update for news shuffle. 2019-09-27 10:03:24 -07:00
SUPPORT.md Get istio.io working with BUILD_WITH_CONTAINER=1 (#4804) 2019-08-16 07:14:29 -07:00
config.toml Introduce top-level News section. (#5060) 2019-09-27 07:09:58 -07:00
mdl.rb Update common files. (#5052) 2019-09-25 06:56:54 -07:00
netlify.toml Update to latest Hugo. (#5058) 2019-09-25 14:07:32 -07:00
tsconfig.json Stop checking in the "generated" directory. (#4365) 2019-06-12 19:48:49 +00:00

README.md

Site Status
istio.io Netlify Status
preliminary.istio.io Netlify Status
archive.istio.io Netlify Status

istio.io

This repository contains the source code for the istio.io, preliminary.istio.io and archive.istio.io sites.

Please see the main Istio README file to learn about the overall Istio project and how to get in touch with us. To learn how you can contribute to any of the Istio components, please see the Istio contribution guidelines.

Editing and building

To learn how to edit and build this repo's content, please refer to Creating and Editing Pages.

Versions and releases

Istio maintains three variations of its public site.

  • istio.io is the main site, showing documentation for the current release of the product.

  • archive.istio.io contains snapshots of the documentation for previous releases of the product. This is useful for customers still using these older releases.

  • preliminary.istio.io contains the actively updated documentation for the next release of the product.

The user can trivially navigate between the different variations of the site using the gear menu in the top right of each page. All three sites are hosted on Netlify.

How versioning works

  • Documentation changes are primarily committed to the master branch of istio.io. Changes committed to this branch are automatically reflected on preliminary.istio.io.

  • The content of istio.io is taken from the latest release-XXX branch. The specific branch that is used is determined by the istio.io Netlify project's configuration.

  • The content of archive.istio.io is taken from the older release-XXX branches. The set of branches that are included on archive.istio.io is determined by the TOBUILD variable in this script.

Publishing content immediately

Checking in updates to the master branch will automatically update preliminary.istio.io, and will only be reflected on istio.io the next time a release is created, which can be several weeks in the future. If you'd like some changes to be immediately reflected on istio.io, you need to check your changes both to the master branch and to the current release branch (named release-XXX such as release-0.7).

This process can be taken care of automatically by our infrastructure. If you submit a PR to the master branch and annotate the PR with the actions/merge-to-release-branch label, then as soon as your PR is merged into master, it will be merged into the current release branch.

Creating a version

Here are the steps necessary to create a new documentation version. Let's assume the current version of Istio is 0.6 and you wish to introduce 0.7 which has been under development.

Creating the release branch

  1. Switch to the istio/istio.io repo and make sure everything is up to date.

  2. Edit the file scripts/gen_archive_site.sh and add the new archive version (in this case release-0.6) to the TOBUILD variable.

  3. Edit the file data/versions.yml. Set the preliminary field to the next Istio release ("0.8") and the main field to the current release ("0.7").

  4. Commit the previous edits to your local git repo.

  5. Create a new release branch off of master, named as release-major.minor, which in this case would be release-0.7. There is one such branch for every release.

  6. In the release branch you created, edit the file data/args.yml. Set the preliminary field to false and the source_branch_name and doc_branch_name fields to the name of the branch, in this case release-0.7.

  7. In the release branch you created, edit the file scripts/grab_reference_docs.sh. Update the branch name for istio.git, api.git, and operator.git to point to the release branch. In this case release-0.7.

  8. In the release branch you created, run make update_ref_docs in order to get the latest reference docs.

  9. Commit the previous edit to your local git repo and push your release branch to GitHub.

Updating preliminary.istio.io

  1. In the master branch, edit the file data/args.yml. Set the version and full_version fields to have the version of the next Istio release, and previous_version to be the version of the previous release. In this case, you would set the fields to "0.8", "0.8.0", and "0.7" respectively.

  2. In the master branch, edit the file data/args.yml. Set the source_branch_name and doc_branch_name fields to master.

  3. In the master branch, edit the file scripts/grab_reference_docs.sh. Ensure the branch name for istio.git, api.git, and operator.git points to the master branch.

  4. Run make update_ref_docs in order to get the latest reference docs.

  5. Commit the previous edits to your local git repo and push the master branch to GitHub.

  6. Wait a while (~2 minutes) and browse preliminary.istio.io to make sure everything looks good.

Updating istio.io

  1. Go to the istio.io project on Netlify

  2. Change the branch that is built from the previous release's branch to the new release branch, in this case release-0.7

  3. Select the option to trigger an immediate rebuild and redeployment.

  4. Once deployment is done, browse istio.io and make sure everything looks good.

Updating archive.istio.io

  1. Go to the Google Custom Search Engine and do the following:

    • Download the archive.istio.io CSE context file from the Advanced tab.

    • Add a new FacetItem at the top of the file containing the previous release's version number. In this case, this would be "V0.6".

    • Upload the updated CSE context file to the site.

    • In the Setup section, add a new site that covers the previous release's archive directory. In this case, the site URL would be archive.istio.io/v0.6/*. Set the label of this site to the name of the facet item created above (V0.6 in this case).

  2. In the previous release's branch (in this case release-0.6), edit the file data/args.yml. Set the archive field to true and the archive_date field to the current date.

  3. In the previous release's branch (in this case release-0.6), edit the file config.toml. Set the disableAliases field to false.

  4. Commit the previous edits to your local git repo and push the previous release's branch to GitHub.

  5. In the archive branch, rebase the branch to have all changes from the current release. In this case, all changes from the release-0.7 branch.

  6. Commit the previous edits to your local git repo and push the archive branch to GitHub.

  7. Wait a while (~15 minutes) and browse archive.istio.io to make sure everything looks good.

Creating a patch release

Creating a new patch release involves modifying a few files:

  1. Create the release note for the release by adding a markdown file in content/en/news/<YEAR>/1.X.Y/index.md, where 1.X.Y is the name of the release. This is where you describe the changes in the release.

  2. Edit the data/args.yml file and change the full_version field to the name of the release.

  3. Run make update_ref_docs to get the latest reference docs.

For the release note file, please look at existing files in the same location for example content and layout.