Skip to content
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

Add tls to gin apiserver #363

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

Gregory-Pereira
Copy link
Collaborator

Addresses: #361
Looking for feedback:

  1. In a subsection of the buildHTTPClient function which previously lived in the sendPostRequest method for the API server, I load in the server CA certificate, which I am not sure I need.
  2. The way I have implemented buildHTTPClient function, it will first try to generate an HTTPS client, and if it fails reading the keys it will instead generate an HTTP client with an error describing as much, and those errors will get picked out of the sendPostRequest function and ignored with appropriate logging. Is this an acceptable implementation? Or if the user specifies they want an HTTPS sessions, and it fails, should the API server just fail to spin?

Changes:

  • env support for the apiserver
  • TLS Secure client enablement

PTAL @vishnoianil @nerdalert

api.logger.Warnf("failed to load client certificate/key: %w", err)
return defaultHTTPClient, fmt.Errorf("Error load client certificate/key, defaulting to TLS Insecure session (http)")
}
// // NOT SURE WE NEED SERVER CA CERT FOR THIS, PLEASE ADVISE
Copy link
Member

Choose a reason for hiding this comment

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

I think you don't need to load it for the client, but the root ca need to be locally deployed (mkcert -i in the apiserver container to make the http request. For prod I think we need to update ansible to make sure that it generates the cert/keys/rootca and deploy those in the gobot http server as well as the apiserver client.

On the side note, I think things will be much better and cleaner once we move to kuberentes/ocp/kind for cert management.

pflag.Parse()

/* ENV support, most variabls take 3 options, with the following priority:
Copy link
Member

Choose a reason for hiding this comment

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

I think let's take these as an input parameter only. We should probably move to urfave/cli? It does pretty clean job with these 3 options. Irrespective of that, I think it would be good if we take care of this (checking env variable) across all the go binaries on the repo in separate PR? wdyt?

InstructLabBotUrl := pflag.String("bot-url", InstructLabBotUrl, "InstructLab Bot URL")
// TLS variables
tlsInsecure := pflag.Bool("tls-insecure", false, "Whether to skip TLS verification")
Copy link
Member

Choose a reason for hiding this comment

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

I think we should introduce a "dev" flag, that basically means --tls-insecure or http. Switching to insecure connection because the tls handshake failed is not a good idea in my opinion. in non-dev mode, if tls fails, just fail, log error and exit. In dev mode, just use --tls-insecure or even http. That will give user the behavior they are expecting from these cli flags.

@@ -39,6 +39,8 @@ services:
network_mode: "host"
depends_on:
- redis
env_file:
Copy link
Member

Choose a reason for hiding this comment

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

I think you also need to fix the deploy/compose/deplo

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.

2 participants