Comments (6)
Actually, action="sture_true" doesn't set the default value to True
. There are many flags in ESP using it, their default values are False
. This behaviors is not as documented here, we have not figured it out why.
For --service_control_network_fail_open, we have to set default value to True.
from esp.
Correct action="store_true" sets the default value to False. And I think this is correct behavoir.
using the flag --service_control_network_fail_open set the value to true and this results in fail open.
without the flag the value is false and connections are not allowed when the control network fails.
What you describe is setting the default value (when the parameter is not specified) to true and the value when the parameter is specified also to true. This makes no sense.
from https://docs.python.org/3/library/argparse.html
'store_true' and 'store_false' - These are special cases of 'store_const' used for storing the values
True and False respectively.
In addition, they create default values of False and True respectively.
So no need to specify defaults when using store_true and notice how they use the opposite default of what they are storing
from esp.
I see your point now; If you just add the flag --service_control_network_fail_open
, its value will be True from store_true, it means "fail_open". By common sense, if it is not specified, it should do the opposite, it should have been "fail_close". But since we have default=True
, it will cause that even it is not specified, it is "fail_open" already. So this flag is not very useful. Unless you specify --service_control_network_fail_open=False, the result is different.
I will suggest to add a new flag: --service_control_network_policy=[open|close], default is open. this is more clear.
This will be added in ESPv2.
from esp.
I can not specify False for the parameter
docker run gcr.io/endpoints-release/endpoints-runtime-secure:1.51 --service_control_network_fail_open=False
usage: start_esp [-h] [-k SERVICE_ACCOUNT_KEY] [-s SERVICE] [-v VERSION]
[-n NGINX_CONFIG] [-p HTTP_PORT] [-P HTTP2_PORT]
[-S SSL_PORT] [-N STATUS_PORT] [-a BACKEND] [-t]
....
start_esp: error: argument --service_control_network_fail_open: ignored explicit argument 'False'
I'm ok with your proposal for v2. But I would make the default false because this is also the curren default. And is more secure: fail safe
Can the code for v1 be fixed in the following way. It will not change the behavior it will only make clear what the behavior is.
parser.add_argument('--service_control_network_fail_open',
action='store_true', help='''
In case of network failures when connecting to Google service control,
the requests will be allowed if this flag is set.
''')
from esp.
Due to Google availability requirement, we have to set network_fail_open to true for default ( for most users). Each individual deployment can decide to alter it. e.g. for your case, you prefer to network_fail_close for security.
But as you pointed it out: --service_control_network_fail_open=False doesn't work. We need to come up a way for users to turn it off.
I will implement GoogleCloudPlatform/esp-v2#345 in v1 too. In this repo.
from esp.
from esp.
Related Issues (20)
- Unable to initialize ESP container using metadata server HOT 3
- esp restarted when it sees RESOURCE_EXHAUSTED from servicemanagement.googleapis.com HOT 1
- GRPC keepalive server side not working HOT 5
- pass zero from grpc to json HOT 2
- ESP on Compute Engine : JWT validation failed: Unable to fetch verification key HOT 11
- HTTP Post x-www-form-urlencoded transcoding HOT 6
- No error response supplied from POST request HOT 1
- Logs displayed as ERROR in Log Viewer HOT 1
- Cannot refer to service name using x-google-backend HOT 3
- Quota limit: 429 after waiting more than 1 minute
- JWT validation failed: Unable to fetch verification key HOT 1
- Malformed WWW-Authenticate header payload returned for UNAUTHORIZED response HOT 3
- Some endpoints need auth others dont. HOT 7
- x-google-jwt-location two entries for a single header HOT 3
- [DELETED]
- RST_STREAM 1 error with GRPC and ESP HOT 13
- ESP build docker failing HOT 1
- Espv1 returns 502/Bad Gateway with code:13 randomly HOT 1
- Modyfing nginx server header
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from esp.