Add AuthenticationPolicy proto #335

diemtvu · 2018-01-31T01:31:41Z

Initial API for Authentication policy. In this version, the policy is able to:

Independently config peer (service-to-service) and end-user authentication.
Allow to use JWT for peer authentication though still need follow up implementation.
Allow to use multiple JWTs simultaneously.

The policy has not yet include 'impersonation' rules, and other options to conditionally activate authentication mechanism (e.g enable/disable a particular end-user auth based on peer identity).

Example specs for use cases:

Turn on mTLS for all service-to-service, and (end-user) JWT for service productpage (will need 2 policies)

metadata:
  name: global
spec:
  target:  # leave blank for all.
  peer:
  - mTLS:

and

metadata
  name: productpage
spec:
  target:
  - name: productpage
    port: 9000
  peer:
  - mTLS:
  end_user:
  - jwt:
      issuer: "https://securetoken.google.com"
      jwks_uri: "https://www.googleapis.com/oauth2/v1/certs"

Using either mTLS or JWT for service-to-service

metadata:
  name: global
spec:
  target:  # leave blank for all.
  peer:
  - mTLS:
  - jwt:
      issuer: "https://securetoken.istio.io"

Design doc: https://docs.google.com/document/d/1ezP4UuOn3JXEs_cXW4GyPGq-Ppq_XhS9-M-lN6ocOA4/edit?ts=5a70c798#heading=h.vel7gfeap92a

xiaolanz · 2018-01-31T06:41:21Z

mixer/v1/config/client/auth.proto

+// - end_user: verify end-user credentials.
+// For each part, if it's not empty, at least one of those listed credential
+// must be provided and  (successfully) verified for the authentication to pass.
+message AuthenticationPolicy {


For new protos, we'd better follow this proto package guide:

https://docs.google.com/document/d/1C_NMYj9ZhdUWwZMWUoX_SLU8VoiV8U8V6yUJVYcdSS8/edit?ts=5a6f888b#heading=h.7zgnj8bwqfld

I think it's better to be in package "istio.authentication.v1alpha1" than mixer.client

The message name can be shorten to "Policy", "mechanism".

+1 for defining these authentication policy in a new package. istio.mixer.v1.config.client is really low-level component level config (i.e. envoy filter) and should be decoupled from policy the user writes.

Done. Move to authentication/v1alpha1/policy.proto

xiaolanz · 2018-01-31T06:49:07Z

mixer/v1/config/client/auth.proto

+// - doesn't contain namespace/domain. All of these are extracted from metadata
+// to construct FQDN service name
+// - port is part of the identifiers.
+message IstioWorkload {


Is it possible to leave out service/workload scope for now?

If we only use global and namespace scoping:

max align with k8s model

easier policy config

service level isolation can be achieved by per service per namespace.

issue with non-k8s identity integration

cannot control over port level. (do we care?)

If we have service/workload level scope,

need to invent our "service/workload" scope concept + format

develop complex scoping conflict resolution/validation -- maybe very hard to use.

additional RBAC if we want to ACL service/workload scope.

A lot of the above points have been discussed extensively. I feel that the gains to introducing service/level scope is very small comparing to the undertakes.

I wonder if we can just start with policy without explicit scoping. If we have to have it later, we can maybe add it by introducing the "binding" config.

We need this to match the policy to the services on which it should be applied. I rename the field so hope it won't be confused with scoping.

xiaolanz · 2018-01-31T06:56:49Z

mixer/v1/config/client/auth.proto

+  // the whole authentication should fail).
+  // The validated credential will be used to extract peer identity (i.e the
+  // source.user attribute in the request to mixer).
+  repeated AuthenticationMechanism peer = 2;


repeated fields must be in purals.

following https://cloud.google.com/apis/design/naming_convention#repeated_field_names

Done. Interesting style difference with google3 :)

douglas-reid · 2018-01-31T16:57:34Z

@geeknoid This feels like a prime candidate for the new proto packages/directories (policy/v1beta/...) rather than adding to the existing structure (mixer/v1/config/client/...). Should this be the first entry in that directory?

qiwzhang · 2018-01-31T17:34:26Z

mixer/v1/config/client/auth.proto

+  // This field is specific for Envoy proxy implementation.
+  // Defines the header location to (re)store the authentiated claims. If not
+  // set, a default value will be used (as of speaking, sec-istio-auth-userinfo)
+  string output_header_location = 8;


This is a hack. we should not need this if Envoy has a way to share request data between different filters.
For now, we have to use http header to pass data between filters.

I'd rather keep this with the other mixer client config for now, until the whole thing can be relocated/update in a cohesive way.

Why should we let users set this? It is our internal plumbing. Users can easily screw us up with typo or mistake.

Agree with Wayne, this is implementation detail and should not be user visible.

qiwzhang · 2018-01-31T17:35:47Z

mixer/v1/config/client/auth.proto

+  // This field is specific for Envoy proxy implementation.
+  // Defines the header location to store the authentiated claims. If blank, a
+  // implementation-specific default value will be used.
+  string output_header_location = 1;


It is clearer to have a specific on/off boolean flag

qiwzhang · 2018-01-31T17:37:54Z

mixer/v1/config/client/auth.proto

+// must be provided and  (successfully) verified for the authentication to pass.
+message AuthenticationPolicy {
+  // If empty, the policy will be applied on all services in the same namespace as the policy.
+  repeated IstioWorkload target = 1;


I think "target" should not be part of Policy. It should be part of "Binding" . Please take a look at EndUserAuthenticationPolicySpecBinding

How would the policy CRD look like if we use "binding"? Diem gave some examples of the authentication CRDs that users can provide with the proposed proto.

liminw · 2018-01-31T18:49:57Z

Agree with @douglas-reid, I think we should introduce a new proto package instead of reusing the current mixer/v1/config/client package. We can call it "authentication/v1alpha1". Alternatively we can add "security" prefix to it ("security/authentication/v1alpha1"), in which case, I will move "rbac" package to "security" directory too.

liminw · 2018-01-31T18:30:34Z

mixer/v1/config/client/auth.proto

+  // This field is specific for Envoy proxy implementation.
+  // Defines the header location to (re)store the authentiated claims. If not
+  // set, a default value will be used (as of speaking, sec-istio-auth-userinfo)
+  string output_header_location = 8;


Agree with Wayne, this is implementation detail and should not be user visible.

liminw · 2018-01-31T18:33:34Z

mixer/v1/config/client/auth.proto

+// Placer holder for mTLS authentication params.
+message MutualTLS {
+  // This field is specific for Envoy proxy implementation.
+  // Defines the header location to store the authentiated claims. If blank, a


typo: authentiated -> authenticated.

liminw · 2018-01-31T18:34:48Z

mixer/v1/config/client/auth.proto

+  // This field is specific for Envoy proxy implementation.
+  // Defines the header location to store the authentiated claims. If blank, a
+  // implementation-specific default value will be used.
+  string output_header_location = 1;


Same as above, the claims are stored in a header is really implementation detail, and should not be set by user.

Removed. My previous plan is let's user to bind the output of each authentication themselves, and the 'attributes extraction' can retrieve data accordingly. However, we might not need it yet if the mechanism is defined inline in the policy, so let's leave it out for now.

liminw · 2018-01-31T18:36:08Z

mixer/v1/config/client/auth.proto

+}
+
+// AuthenticationMechanism defines one particular type of authentication (i.e
+// mutual TLS, JWT etc). The type can be progammatically determine by checking


typo: determined

ayj · 2018-01-31T23:55:09Z

It's been said by others already, but it would be useful to create a new package to hold the user-facing authentication policy. We can keep the existing mixer client policy as an implementation detail between Pilot and mixerclient and deal with refactoring that later. Things like jwks_cluster, output_header_location, and any other envoy/proxy/mixerclient specific bits can remain mixerclient config.

ayj · 2018-02-01T00:47:15Z

authentication/v1alpha1/policy.proto

+}
+
+message Destination {
+  // REQUIRED. The name can be a short name or a fully qualified domain


Is it possible to apply policy at ingress (i.e. gateway)?

Should be, though some mode (e.g mTLS) maybe not applicable

ZackButcher · 2018-02-01T00:48:51Z

authentication/v1alpha1/policy.proto

+  // address.
+  // If short names are used, the FQDN of the service will be resolved in a
+  // platform specific manner.
+  string name = 1;


How does this relate to DestinationRule's name? We've also moved to accepting wildcard domains in many of these fields; is that allowed here too? cc @rshriram @louiscryan

BTW feels like we need a common type for this, it's popping up a lot. Previously we had IstioService for this concept, but it went away.

Right, forgot we renamed IstioService to Destination

api/routing/v1alpha2/route_rule.proto

Line 266 in e419233

message Destination {

ayj · 2018-02-01T00:50:24Z

authentication/v1alpha1/policy.proto

+// the type of the "params" field.
+message Mechanism {
+  oneof params {
+    bool none = 1;


Why is none needed?

It's not an enum so we don't get a default value. However, I think using Empty would be better. (E.g. what does none: False even mean?)

For example, what's the difference between an empty (or null) peers array and a peers array with none?

None is one kind of authentication. For example, it can be used to define a service to require EUC, except for request come from specific peers. However, I haven't defined the applied condition in this PR yet.

peer:

mtls:
end_user:

jwt: .....

none:
in: "service_account_A"

Interesting - thanks for the explanation. It looks like none should really be a specific type and not a boolean or Empty so it can be extended in the future, e.g.

message None { // TODO - add conditions to require EUC? }

ayj · 2018-02-01T00:51:41Z

authentication/v1alpha1/policy.proto

+  oneof params {
+    bool none = 1;
+    MutualTLS mtls = 2;
+    istio.mixer.v1.config.client.JWT jwt = 3;


Can you define a new JWT type under authentication/v1alpha1 for user-facing config with the envoy specific bits stripped out?

+1, this should be elevated up to a higher level; istio.authentication.v1alpha1.JWT seems reasonable and can be re-used in Mixer.

Done. Not sure if I strip out the right fields though. PTAL

ZackButcher · 2018-02-01T00:59:46Z

authentication/v1alpha1/policy.proto

+message Policy {
+  // List of destinations (workloads) that the policy should be applied on.
+  // If empty, policy will be used on all destinations in the same namespace.
+  repeated Destination match = 1;


I think we'll also need to be able to match on labels.

Maybe. I'm just not sure mTLS setting in particular can support that.

On the other hand, I really temp to use the route_rule.Destination. Do you think it's a good idea?

Yeah, that seems most reasonable.

ZackButcher · 2018-02-01T01:38:21Z

authentication/v1alpha1/policy.proto

@@ -0,0 +1,182 @@
+// Copyright 2017 Istio Authors


ZackButcher · 2018-02-01T01:40:13Z

authentication/v1alpha1/policy.proto

+//           jwks_uri: "https://www.googleapis.com/oauth2/v1/certs"
+//           locations:
+//           - header: x-goog-iap-jwt-assertion
+message Policy {


@rshriram @diemtvu: one more thought: is this something that can/should be part of DestinationRule? Would the configuration be more natural there? We already have other TLS settings there.

Either way we should rationalize the TLS settings there with the ones defined here.

Not sure, I was once told to stay away from DestinationRule :) (we want to separate networking and security). Not sure if the perspective now shifted.

Regardless, I rather keep them separated for now, and see how they evolve and decide later. What do you think?

douglas-reid · 2018-02-01T02:14:12Z

authentication/v1alpha1/policy.proto

+// AuthenticationMechanism defines one particular type of authentication (i.e
+// mutual TLS, JWT etc). The type can be progammatically determine by checking
+// the type of the "params" field.
+message Mechanism {


nit: the comment refers to this as "AuthenticationMechanism" but the message name is "Mechanism". We should use one or the other.

Change back to AuthenticationMechanism

douglas-reid · 2018-02-01T02:15:49Z

authentication/v1alpha1/policy.proto

+  }
+}
+
+// AuthenticationPolicy binds credentials to workload(s).


Is it AuthenticationPolicy or Policy ? We should be consistent. I think this should read:

// Policy binds credentials to workload(s), defining an authentication policy. // A policy is composed of two-part authentication: // - peers: ...

Related, I think the examples need to be updated to use the plurals (peers, end_users).

Also please use camelCase for YAML field names in examples.

douglas-reid · 2018-02-01T02:17:21Z

authentication/v1alpha1/policy.proto

+message Policy {
+  // List of destinations (workloads) that the policy should be applied on.
+  // If empty, policy will be used on all destinations in the same namespace.
+  repeated istio.routing.v1alpha2.Destination match = 1;


@wora should this be plural? I realize that would be inconsistent with other usages of match in the API, but it matches the style guidelines, I believe.

What is the recommendation here? If it is to prefer match to matches, should we update our Style Guide to mention this exception?

douglas-reid · 2018-02-01T02:26:33Z

authentication/v1alpha1/policy.proto

+// Policy to enable mTLS, and use JWT for productpage:9000
+//
+//     apiVersion: config.istio.io/v1alpha2
+//     kind: RouteRule


i'm confused by the CR examples. Should these be:

apiVersion: config.istio.io/**v1alpha1** kind: **Policy**

?

And if so, do we need to call these AuthenticationPolicy so that it isn't a generic Policy?

Good catch, cut-and-paste error.

Regarding the proto name, I think it's not necessary to be the same as 'kind', though it seems to be the convention so far (https://github.com/istio/istio/blob/master/pilot/pkg/model/config.go#L307)

Do you have any strong preference?

wora · 2018-02-01T04:39:06Z

authentication/v1alpha1/policy.proto

+//     jwks_uri: https://example.com/.well-known/jwks.json
+//
+message JWT {
+  // Identifies the principal that issued the JWT. See


principal => issuer

wora · 2018-02-01T04:45:42Z

authentication/v1alpha1/policy.proto

+      string query = 2;
+    }
+  }
+  repeated Location locations = 6;


Do we really need the Location message? I think this works just fine:

repeated string jwt_headers; repeated string jwt_params;

This part is very unlikely to change, so the extra nesting doesn't seem to add much value.

I copied this from the old jwt proto. @ayj @qiwzhang what do you think about this?

I am fine with this change.

Is ordering important? The previous version searched location in order of appearance.

ayj · 2018-02-01T19:55:04Z

authentication/v1alpha1/policy.proto

+message AuthenticationPolicy {
+  // List of destinations (workloads) that the policy should be applied on.
+  // If empty, policy will be used on all destinations in the same namespace.
+  repeated istio.routing.v1alpha2.Destination match = 1;


@wora on API guidance for whether its preferred to reuse types and implications on backwards compatibility. If this is a more core type maybe it belongs in a different package?

geeknoid · 2018-02-05T19:12:48Z

authentication/v1alpha1/policy.proto

+
+import "routing/v1alpha2/route_rule.proto";
+
+// $title: Authentication Policy


This isn't quite right.

$title and $overview and $location should be "floating" comments, not attached to any element. So add a blank line right after these definitions.

Second, you should add a user-friendly comment on top of the package definition which will displayed in the docs on istio.io.

geeknoid · 2018-02-05T19:13:11Z

authentication/v1alpha1/policy.proto

+
+option go_package = "istio.io/api/authentication/v1alpha1";
+
+// Place holder for None authentication params


Placeholder is one word

geeknoid · 2018-02-05T19:13:34Z

authentication/v1alpha1/policy.proto

+// authentication flow.
+//
+// Example,
+//


Add ```yaml around the code block

geeknoid · 2018-02-05T19:14:13Z

authentication/v1alpha1/policy.proto

+//
+message Jwt {
+  // Identifies the issuer that issued the JWT. See
+  // https://tools.ietf.org/html/rfc7519#section-4.1.1


Make this a markdown link:

xxx

geeknoid · 2018-02-05T19:14:45Z

authentication/v1alpha1/policy.proto

+  // The service name will be accepted if audiences is empty.
+  //
+  // Example:
+  //


Add ```yaml and remove extra spaces at the start of the lines in the code block.

geeknoid · 2018-02-05T19:15:42Z

authentication/v1alpha1/policy.proto

+//
+// Examples:
+// Policy to enable mTLS for all services in namespace frod
+//


Add ```yaml around code block and remove spaces at the start of each line.

geeknoid · 2018-02-05T19:16:03Z

authentication/v1alpha1/policy.proto

+//
+// Policy to enable mTLS, and use JWT for productpage:9000
+//
+//     apiVersion: authentication.istio.io/v1alpha1


Add ```yaml, etc.

geeknoid · 2018-02-05T19:16:40Z

authentication/v1alpha1/policy.proto

+  // will be validated in sequence, until the first one satisfied. If none of
+  // the specified mechanism valid, the whole authentication should fail.
+  // On the other hand, the first valid credential will be used to extract
+  // peer identity (i.e the source.user attribute in the request to mixer).


mixer -> Mixer

xiaolanz · 2018-02-05T19:38:54Z

authentication/v1alpha1/policy.proto

+message Policy {
+  // List of destinations (workloads) that the policy should be applied on.
+  // If empty, policy will be used on all destinations in the same namespace.
+  repeated istio.routing.v1alpha2.Destination destinations = 1;


I think that Destination should be refactor into a istio.common place. then, both route rule and authentication policy reference to it. We should create that common package and copy the Destination message there. And then, another PR to switch route rule to use the new message.

@wora is there an existing pattern we can follow to do thi?

Should I re-introduce the Destination message specific for authN (which we may want a list of ports instead a single one, and probably without label as it's unclear we are able to use that information yet), and waive the refactor decision till later?

How would I apply policy at the edge of the mesh with destination (i.e. ingress/gateway) or restrict to specific protocols/paths/methods? RouteRule has some notion of binding to a gateway or host/service with further protocol specific refinement. Do we need something similar here?

ZackButcher · 2018-02-05T17:41:10Z

authentication/v1alpha1/policy.proto

+  //
+  // Example: https://securetoken.google.com
+  // Example: [email protected]
+  //


remote empty comment line

ZackButcher · 2018-02-05T17:41:25Z

authentication/v1alpha1/policy.proto

+//     audiences:
+//     - bookstore_android.apps.googleusercontent.com
+//       bookstore_web.apps.googleusercontent.com
+//     jwks_uri: https://example.com/.well-known/jwks.json


camel case yaml field names: jwksUri

ZackButcher · 2018-02-05T22:24:49Z

authentication/v1alpha1/policy.proto

+  // Google service account).
+  //
+  // Example: https://www.googleapis.com/oauth2/v1/certs
+  string jwks_uri = 3;


I know this is copied over from the Google API auth protos but do we know why is this jwks and not jwtks?

afaik, the name is based on OpenID spec.

jwks_uri is also used in OpenID spec (see https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata)

* cluster configuration * nits

ZackButcher · 2018-02-06T18:35:11Z

authentication/v1alpha1/policy.proto

+// Policy to enable mTLS, and use JWT for productpage:9000
+//
+// ```yaml
+//     apiVersion: authentication.istio.io/v1alpha1


Sorry, only do one or the other: either have ```yaml blocks, or indent by four spaces, but not both.

Move template and valuetype to mixer/adapter/model/v1beta

diemtvu · 2018-02-06T21:09:57Z

Ideally, we do want to use the same notion, but I have a hard time to see how exactly all pieces fit altogether, given they are all work-in-progress. I'd like to wait a bit until all implementation details settle down on that side. Does this make sense?

…

On Tue, Feb 6, 2018 at 11:07 AM, Jason Young ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In authentication/v1alpha1/policy.proto <#335 (comment)>: > +// port: +// number: 9000 +// peers: +// - mtls: +// endUsers: +// - jwt: +// issuer: "https://securetoken.google.com" +// audiences: +// - "productpage" +// jwksUri: "https://www.googleapis.com/oauth2/v1/certs" +// locations: +// - header: x-goog-iap-jwt-assertion +message Policy { + // List of destinations (workloads) that the policy should be applied on. + // If empty, policy will be used on all destinations in the same namespace. + repeated istio.routing.v1alpha2.Destination destinations = 1; How would I apply policy at the edge of the mesh with destination (i.e. ingress/gateway) or restrict to specific protocols/paths/methods? RouteRule has some notion of binding to a gateway or host/service with further protocol specific refinement. Do we need something similar here? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#335 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AX99cZAa4obn_kf9EqoVwZHa9CGtyd_Cks5tSKL2gaJpZM4RzSWG> .

-- Diem Vu | Software Engineer | [email protected] | +1 408-215-8127

googlebot · 2018-02-07T01:42:42Z

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this State. It's up to you to confirm consent of the commit author(s) and merge this pull request when appropriate.

istio-testing · 2018-02-07T01:44:18Z

@diemtvu: The following test failed, say /retest to rerun them all:

Test name	Commit	Details	Rerun command
prow/api-presubmit.sh	`75db816`	link	`/test api-presubmit`

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

diemtvu · 2018-02-07T02:17:28Z

I did something bad in the last rebase(s) so I create new PR #361 to replace this.

* Revert "Upgrade gRPC to v1.3.4 (istio#335)" This reverts commit f9bf1d9. * Revert "Update gRPC to v1.3.2 (istio#315)" This reverts commit 6f8953d.

Automatic merge from submit-queue. [DO NOT MERGE] Auto PR to update dependencies of mixerclient This PR will be merged automatically once checks are successful. ```release-note none ```

diemtvu requested review from douglas-reid, geeknoid, kyessenov, rshriram and ZackButcher as code owners January 31, 2018 01:31

googlebot added the cla: yes Set by the Google CLA bot to indicate the author of a PR has signed the Google CLA. label Jan 31, 2018

diemtvu assigned diemtvu, qiwzhang, liminw, lei-tang, ayj and xiaolanz and unassigned diemtvu Jan 31, 2018

xiaolanz suggested changes Jan 31, 2018

View reviewed changes

qiwzhang reviewed Jan 31, 2018

View reviewed changes

liminw reviewed Jan 31, 2018

View reviewed changes

ayj reviewed Feb 1, 2018

View reviewed changes

ZackButcher reviewed Feb 1, 2018

View reviewed changes

diemtvu force-pushed the authn branch from 5070c99 to 2261e34 Compare February 1, 2018 00:49

ayj reviewed Feb 1, 2018

View reviewed changes

ZackButcher reviewed Feb 1, 2018

View reviewed changes

authentication/v1alpha1/policy.proto Outdated

@@ -0,0 +1,182 @@

// Copyright 2017 Istio Authors

Copy link

Contributor

ZackButcher Feb 1, 2018

Choose a reason for hiding this comment

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

2018

ZackButcher reviewed Feb 1, 2018

View reviewed changes

douglas-reid reviewed Feb 1, 2018

View reviewed changes

wora reviewed Feb 1, 2018

View reviewed changes

ayj reviewed Feb 1, 2018

View reviewed changes

diemtvu force-pushed the authn branch from b81b6ad to bb432c3 Compare February 5, 2018 17:36

diemtvu and others added 4 commits February 5, 2018 09:45

Fix merge.

c07f4ae

added documentation about TCP Egress Rules, CIDR notation (istio#346)

71303d2

Rename AuthenticationPolicy to Policy.

762d4c1

Rename AuthenticationPolicy to Policy.

2a17f61

geeknoid reviewed Feb 5, 2018

View reviewed changes

xiaolanz reviewed Feb 5, 2018

View reviewed changes

More comment clean up.

c0b6ac3

ZackButcher reviewed Feb 5, 2018

View reviewed changes

diemtvu and others added 2 commits February 5, 2018 15:07

More comment clean up.

74d9a80

Configurable mixer cluster names for mixer filter (istio#358)

ebec456

* cluster configuration * nits

ZackButcher reviewed Feb 6, 2018

View reviewed changes

introduce api/mixer/adapter/model/v1beta (istio#359)

12edb32

Move template and valuetype to mixer/adapter/model/v1beta

diemtvu and others added 2 commits February 6, 2018 13:34

Correct yaml comments.

ed33c0b

add missing docs for mixerclient filter config (istio#353)

4adeda7

xiaolanz approved these changes Feb 7, 2018

View reviewed changes

diemtvu added 2 commits February 6, 2018 17:37

Nits

d4b189d

Merge branch 'authn' of github.com:diemtvu/api into authn

75db816

googlebot added cla: no Set by the Google CLA bot to indicate the author of a PR has not signed the Google CLA. and removed cla: yes Set by the Google CLA bot to indicate the author of a PR has signed the Google CLA. labels Feb 7, 2018

diemtvu mentioned this pull request Feb 7, 2018

Add proto for authentication policy. #361

Merged

diemtvu closed this Feb 7, 2018

diemtvu deleted the authn branch February 14, 2018 22:56

incfly pushed a commit to incfly/api that referenced this pull request Jun 13, 2018

Upgrade gRPC to v1.3.4 (istio#335)

f9bf1d9

incfly pushed a commit to incfly/api that referenced this pull request Jun 13, 2018

Revert gRPC Upgrades (istio#340)

729519e

* Revert "Upgrade gRPC to v1.3.4 (istio#335)" This reverts commit f9bf1d9. * Revert "Update gRPC to v1.3.2 (istio#315)" This reverts commit 6f8953d.


		import "routing/v1alpha2/route_rule.proto";

		// $title: Authentication Policy


		option go_package = "istio.io/api/authentication/v1alpha1";

		// Place holder for None authentication params

Add AuthenticationPolicy proto #335

Add AuthenticationPolicy proto #335

Conversation

diemtvu commented Jan 31, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

douglas-reid commented Jan 31, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

liminw commented Jan 31, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ayj commented Jan 31, 2018

ayj Feb 1, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ZackButcher Feb 1, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ayj Feb 1, 2018 •

edited

Loading

ZackButcher Feb 1, 2018 •

edited

Loading