-
Notifications
You must be signed in to change notification settings - Fork 9
bmz-UID2-4612 add endpoint to serve operator config #200
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 11 commits
d9d93fd
37016bc
317c2df
4e042bf
98cf9bf
900695c
d38be53
717f4b3
bf523c7
2bcff62
eabb06d
bb29d9c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,6 @@ | ||
| { | ||
| "identity_token_expires_after_seconds": 3600, | ||
| "refresh_token_expires_after_seconds": 86400, | ||
| "refresh_identity_token_after_seconds": 900, | ||
| "sharing_token_expiry_seconds": 2592000 | ||
| } | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -17,6 +17,8 @@ | |
| import com.uid2.shared.store.reader.RotatingCloudEncryptionKeyProvider; | ||
| import io.vertx.core.*; | ||
| import io.vertx.core.buffer.Buffer; | ||
| import io.vertx.core.file.FileSystem; | ||
| import io.vertx.core.http.HttpHeaders; | ||
| import io.vertx.core.json.JsonArray; | ||
| import io.vertx.core.json.JsonObject; | ||
| import io.vertx.ext.web.client.HttpResponse; | ||
|
|
@@ -40,6 +42,8 @@ | |
| import javax.crypto.Cipher; | ||
| import java.io.ByteArrayInputStream; | ||
| import java.net.URL; | ||
| import java.nio.file.Files; | ||
| import java.nio.file.Paths; | ||
| import java.security.KeyPair; | ||
| import java.security.KeyPairGenerator; | ||
| import java.security.SecureRandom; | ||
|
|
@@ -70,12 +74,14 @@ public class TestCoreVerticle { | |
| private JwtService jwtService; | ||
| @Mock | ||
| private RotatingCloudEncryptionKeyProvider cloudEncryptionKeyProvider; | ||
| @Mock | ||
| private FileSystem fileSystem; | ||
|
|
||
| private AttestationService attestationService; | ||
| private String operatorConfig; | ||
|
|
||
| private static final String attestationProtocol = "test-attestation-protocol"; | ||
| private static final String attestationProtocolPublic = "trusted"; | ||
|
|
||
| @BeforeEach | ||
| void deployVerticle(TestInfo info, Vertx vertx, VertxTestContext testContext) throws Throwable { | ||
| JsonObject config = new JsonObject(); | ||
|
|
@@ -116,7 +122,18 @@ void deployVerticle(TestInfo info, Vertx vertx, VertxTestContext testContext) th | |
| } | ||
| }); | ||
|
|
||
| CoreVerticle verticle = new CoreVerticle(cloudStorage, authProvider, attestationService, attestationTokenService, enclaveIdentifierProvider, operatorJWTTokenProvider, jwtService, cloudEncryptionKeyProvider); | ||
| operatorConfig = Files.readString(Paths.get(com.uid2.core.Const.OPERATOR_CONFIG_PATH)).trim(); | ||
|
|
||
| when(fileSystem.readFile(anyString(), any())).thenAnswer(invocation -> { | ||
| String path = invocation.getArgument(0); | ||
| if (Objects.equals(path, com.uid2.core.Const.OPERATOR_CONFIG_PATH)) { | ||
| Handler<AsyncResult<Buffer>> handler = invocation.getArgument(1); | ||
| handler.handle(Future.succeededFuture(Buffer.buffer(operatorConfig))); | ||
| } | ||
BehnamMozafari marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| return null; | ||
| }); | ||
|
|
||
| CoreVerticle verticle = new CoreVerticle(cloudStorage, authProvider, attestationService, attestationTokenService, enclaveIdentifierProvider, operatorJWTTokenProvider, jwtService, cloudEncryptionKeyProvider, fileSystem); | ||
| vertx.deployVerticle(verticle, testContext.succeeding(id -> testContext.completeNow())); | ||
|
|
||
| } | ||
|
|
@@ -874,4 +891,34 @@ void keysRefreshSuccessNoHeaderVersion(Vertx vertx, VertxTestContext testContext | |
| } | ||
| }); | ||
| } | ||
|
|
||
| @Test | ||
| void getConfigSuccess(Vertx vertx, VertxTestContext testContext) { | ||
| JsonObject expectedConfig = new JsonObject(operatorConfig); | ||
|
|
||
| fakeAuth(Role.OPERATOR); | ||
|
|
||
| // Make HTTP Get request to operator config endpoint | ||
| this.get(vertx, Endpoints.OPERATOR_CONFIG.toString(), testContext.succeeding(response -> testContext.verify(() -> { | ||
| assertEquals(200, response.statusCode()); | ||
| assertEquals("application/json", response.getHeader(HttpHeaders.CONTENT_TYPE)); | ||
| JsonObject actualConfig = new JsonObject(response.bodyAsString()); | ||
| assertEquals(expectedConfig, actualConfig); | ||
| testContext.completeNow(); | ||
| }) | ||
| )); | ||
| } | ||
|
|
||
| @Test | ||
| void getConfigInvalidJson(Vertx vertx, VertxTestContext testContext) { | ||
| operatorConfig = "invalid config"; | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it would be better if we check json config on startup to make sure it is valid. That will be easier to debug then having it only checked when operator call.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Since the config will be updated at runtime through a configmap, it might not be sufficient to only check it at startup, but checking it whenever it has changed seems like a good idea. I'll implement this in a future mr. Thanks for the feedback! |
||
|
|
||
| fakeAuth(Role.OPERATOR); | ||
|
|
||
| this.get(vertx, Endpoints.OPERATOR_CONFIG.toString(), testContext.succeeding(response -> testContext.verify(() -> { | ||
| assertEquals(500, response.statusCode()); | ||
| testContext.completeNow(); | ||
| }) | ||
| )); | ||
| } | ||
| } | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggest using an object ;
OperatorRunTimeConfig (or similar) and using that instead of JsonObject
It will improve readability as we know what exactly we need/have to set in config.
Also in followup MRs; Please make sure we remove the unwanted config from operators
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@BehnamMozafari Could you give more context why we need to use an additional config file for this? The current config hierarchy - default, local, integ, prod config already covers config for each env. I am not sure where operator-config.config is fit into this hierarchy.
If we want to serve the run time config (config might be changed at start time, as the config can also be taken from/overwrited by env vars), we should read them from the run time system and send in api.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(I will explain, please correct if I am wrong @BehnamMozafari )
this is the config, core servers to operators. We are adding this new operator-config in core that servers runtime config core sets for operators.
Since it is not core config, we added a new file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Abu, yep that's correct, the operator-config is going to be served to operator and will be mounted to core using a configmap.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, this would help in validating any updates to operator-config. I'm considering implementing this in a future MR. However, a concern is that it would require us to redeploy core whenever we want to add a new operator config value to be consumed at run time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How would we add a new operator config value with the JsonObject implementation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Stronger typing and validation on config updates can reduce risks.
Adding new config_values without an E2E test offers no guarantee it won't break. If it passes E2E tests, it's safe for release, otherwise, prioritizing and addressing those issues would be essential.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the current implementation, we would need to add the new value to the configmap in the deployment repo, we would also have to make the changes in operator to apply the new config value.