You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Dec 20, 2022. It is now read-only.
Since provider sidecar is implemented in go, we decided to find a library that supports like reverse proxy feature in gRPC interface, and we found [this library](https://github.com/mwitkow/grpc-proxy).
6
+
7
+
## Making code changes
8
+
9
+
We implemented the feature with the below attention:
10
+
11
+
1. Match the current code structure
12
+
2. No breakable changes from the user side
13
+
14
+
For 2, it is mainly focusing on the provider sidecar configuration.
15
+
16
+
When the user uses the legacy provider sidecar configuration file with the new version, it will still work without any update on the configuration file.
It retrieves the role token from the gRPC metadata, and authorize it using the athenz-authorizer.
53
+
54
+
If authorization succeeded, the gRPC request will proxy to the backend.
55
+
56
+
## Configuration
57
+
58
+
In handler layer, the gRPC call will be authenticated and authorized by athenz policy.
59
+
60
+
Setting the athenz policy is almost the same as before, other than the resource set on the resource.
61
+
62
+
The resource name is defined in the proto files [here](https://github.com/vdaas/vald/tree/master/apis/proto/v1/vald), following by the following scheme.
63
+
64
+
`/<package name>.<service name>/<rpc name>`
65
+
66
+
For example, Vald provides an interface for users to insert vector. Here is the proto file:
Following the syntax, to configure the resource in policy should be `/vald.v1.insert/insert`.
106
+
107
+
For another gRPC interfaces, it should be the same.
108
+
109
+
The policy action is `grpc`, which is hardcoded in the source code.
110
+
111
+
## Design
112
+
113
+
### Athenz Provider Sidecar
114
+
115
+
Athenz provider sidecar can start with either gRPC mode and HTTP mode at the same time. The reasons are:
116
+
117
+
- We wanted to make minimal changes to it
118
+
- Supporting both gRPC and HTTP mode at the same time causes big changes on configuration file, and it may lead to breaking changes
119
+
- Also there are no such requirement from users
120
+
121
+
### Athenz Policy
122
+
123
+
To design Athenz policy configuration, there are 2 fields we need to think about:
124
+
125
+
- Action
126
+
- Resources
127
+
128
+
#### Policy Action
129
+
130
+
In the world of HTTP, different HTTP methods are supported, like `GET` and `POST`, and these value is used in action field.
131
+
132
+
But in gRPC, there are no such concept.
133
+
For each RPC endpoint, only 1 resource is supported.
134
+
135
+
But [gRPC supports 4 different types](https://grpc.io/docs/what-is-grpc/core-concepts/#rpc-life-cycle):
136
+
137
+
- Unary RPC
138
+
- Server streaming RPC
139
+
- Client streaming RPC
140
+
- Bidirectional streaming RPC
141
+
142
+
Due to the limitation of gRPC, each RPC endpoint support only 1 resource, a separate endpoint is required for each RPC type.
143
+
144
+
For the reasons above, currently Vald team decided to hardcode `grpc` in the action field and use the when performing authentication and authorization check.
0 commit comments