Skip to content

Conversation

smawson
Copy link
Contributor

@smawson smawson commented Sep 30, 2017

Also cleaned up a few other items while I was at it.

Also cleaned up a few other items such as the Pilot entry.
@smawson smawson added this to the Istio 0.2 milestone Sep 30, 2017
@smawson smawson self-assigned this Sep 30, 2017
@istio-testing
Copy link
Contributor

Jenkins job istio.github.io/presubmit passed

@@ -2,5 +2,5 @@
title: Istio-Auth
type: markdown
---
Istio-Auth provides strong service-to-service and end-user authentication using mutual TLS, with built-in identity and
credential management. Learn more about Istio-Auth [here](../concepts/network-and-auth/auth.html).
Provides strong service-to-service authentication using mutual TLS, with built-in identity and credential management.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of "Provides", perhaps "Supports"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tried it and it felt wrong. I think we need to rewrite auth here and give a better description, I'll talk to Wencheng. For now will leave as-is.

@@ -2,4 +2,4 @@
title: Service Producer
type: markdown
---
The agent that creates a service by writing source code.
The agent that creates a **Service** and manages which **Service Consumers** may use it.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The operator is really the one that decides who can use the service, so I'd strike that second part of the sentence.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're talking about different roles here, it is the same person, but in their provider role that they are deciding who can access, not as operator. Or at least that's what we usually mean by the producer/consumer/operator split. We could maybe just delete producer/consumer from the glossary since they're more about API management than service management?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think removing these for the time being would be good. We'll have a better grip on things for 0.3

service has a default version consisting of all its instances.
Distinct variants of a **Service**, typically backed by a different version of a **Workload** binary.
Common scenarios where multiple **Service Versions** may be used include A/B testing, canary rollouts, etc.
Each **Service** has a default **Service Version** consisting of all its **Service Endpoints**.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm puzzled by what this means. I don't think we can say that a "version consists of endpoints". Maybe just drop the "consisting of all its Service Endpoints" part?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, dropped.

use to refer to the functionality being called. Service instances are
pods/VMs/containers that implement the service.
A delineated group of related behaviors within a **Service Mesh**. Services are named using a **Service Name**,
and Istio policies such as load balancing and routing are applied to **Service Names**.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"applied to" isn't right. "applied to services using service names". Or maybe just "applied using service names"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, done.

pods/VMs/containers that implement the service.
A delineated group of related behaviors within a **Service Mesh**. Services are named using a **Service Name**,
and Istio policies such as load balancing and routing are applied to **Service Names**.
A **Service** is typically materialized by one or more **Service Endpoints**.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

, and may consists of multiple co-existent service versions.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@@ -0,0 +1,7 @@
---
title: Workload
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Workload Name

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done, good catch.

Istio service-to-service authentication is used to produce the **Workload Principal**.
By default **Workload Principals** are compliant with the SPIFFE ID format.
* Multiple **Workloads** may share the same **Workload Principal**, but each **Workload** has a single canonical **Workload Principal**.
* **Worklooad Principals** are accessible in Istio configuration as the `source.user` and `destination.user` attributes.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shame we can be consistent here with "user" vs "principal".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also typo.. Worklooad (double o)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah we want to change this in an upcoming release but didn't want to do it right before 0.2.

Plan is to rename to source.principal and destination.principal, and we'll also have request.auth.principal for auth credentials.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed typo.

---
A unique name for a **Workload**, identifying it within the **Service Mesh**.
Unlike **Service Name** and **Workload Principal**, **Workload Name** is not a strongly verified property and should not be used when enforcing ACLs.
* **Workload Names** are accessible in Istio configuration as the `source.name` and `destination.name` attributes.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shame this isn't source.workload.name and destination.workload.name.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it matters, we've been using source.uid and destination.uid to denote the workload IDs.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So what's the relationship between source.name and source.uid? Should we have a glossary entry for Workload Id? Given workload id, why do we need workload name?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a glossary entry for Workload ID.

Both are useful, since workload name is a natural grouping of workload IDs and more useful in dashboards.

Copy link
Member

@rshriram rshriram left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sans typo and fixing links

@istio-testing
Copy link
Contributor

Jenkins job istio.github.io/presubmit passed

@rshriram rshriram merged commit 43e4ba2 into istio:master Oct 2, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants