Assigned
Status Update
Comments
sh...@google.com <sh...@google.com> #2
Could you share you cloudflare config ? Disabled always use HTTPS ? Created WAF rule to allow certificate renewal ?
he...@google.com <he...@google.com> #3
The Cloudflare settings, at the time of generating the certs, when the
error showed for the --no-default-url but worked for the ones with
--default-url were:
- The Development mode was turned on, which temporarily bypasses
Cloudfare's cache
- In the SSL/TLS section:
- *Total TLS was kept ON* with "Google Trusted Services" as the selected
Certificate Authority.
- *Always Use HTTPS was turned OFF* (because this was causing issues
months ago, and the logs show that the requests to generate certs were
being done through regular HTTP call (which I don't agree with - but you
can look online at how some users got some of the certs problems resolved
by turning this feature off)
- HTTP Strict Transport Security (HSTS) was not changed and it is set to:
- Enforce web security policy for your website.
Status: On
Max-Age: 5 months
Include subdomains: On
Preload: On
- *The minimum TLS version was downgraded to TLS 1.0 (default)*
- *Opportunistic Encryption was turned off*
- *TLS 1.3 was turned off*
- *Automatic HTTPS Rewrites was turned off*
- *Encrypted Client Hello was turned off*
I don't have WAF rules to allow certificate renewal, and I don't even know
that would be configured, as I assume Google should provide the config
setting to set the WAF with Cloudflare.
The issue is that if I deploy two cloud-run endpoints, one with
the—-no-default-url flag and the other with the—- URL flag, and I generate
a domain mapping at the same time, the one with the—-no-default-flag is the
only one that fails, and I get the "internal error" on Google's side, not
mine.
There are two issues. The first is the cloud run flag preventing SSL certs
from being generated, and the second is the certs not regenerating after
they expire. They have an expiration of three months.
On Sun, Oct 27, 2024 at 5:36 PM <buganizer-system@google.com> wrote:
error showed for the --no-default-url but worked for the ones with
--default-url were:
- The Development mode was turned on, which temporarily bypasses
Cloudfare's cache
- In the SSL/TLS section:
- *Total TLS was kept ON* with "Google Trusted Services" as the selected
Certificate Authority.
- *Always Use HTTPS was turned OFF* (because this was causing issues
months ago, and the logs show that the requests to generate certs were
being done through regular HTTP call (which I don't agree with - but you
can look online at how some users got some of the certs problems resolved
by turning this feature off)
- HTTP Strict Transport Security (HSTS) was not changed and it is set to:
- Enforce web security policy for your website.
Status: On
Max-Age: 5 months
Include subdomains: On
Preload: On
- *The minimum TLS version was downgraded to TLS 1.0 (default)*
- *Opportunistic Encryption was turned off*
- *TLS 1.3 was turned off*
- *Automatic HTTPS Rewrites was turned off*
- *Encrypted Client Hello was turned off*
I don't have WAF rules to allow certificate renewal, and I don't even know
that would be configured, as I assume Google should provide the config
setting to set the WAF with Cloudflare.
The issue is that if I deploy two cloud-run endpoints, one with
the—-no-default-url flag and the other with the—- URL flag, and I generate
a domain mapping at the same time, the one with the—-no-default-flag is the
only one that fails, and I get the "internal error" on Google's side, not
mine.
There are two issues. The first is the cloud run flag preventing SSL certs
from being generated, and the second is the certs not regenerating after
they expire. They have an expiration of three months.
On Sun, Oct 27, 2024 at 5:36 PM <buganizer-system@google.com> wrote:
--
*-*
------------------------------
This email and any files transmitted with it may contain confidential
information and is intended only for the individual or entity to whom they
are addressed. If you are not the intended recipient you are notified that
disclosing, copying, distributing or taking any action in reliance on the
contents of this information is strictly prohibited. If you have received
this transmission in error, please notify the sender and delete this email
from your computer. Email transmission cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses.
------------------------------
Electronic Communications Privacy Act, 18 U.S.C. Sections 2510-2521.
------------------------------
Description
Summary:
While testing a notebook for AutoML Tables on Managed Pipeline the resulting Dataflow jobs fail after 30s in a NOT_STARTED state.
Errors logged within both Vertex AI and Dataflow do not provide any information to help troubleshoot the issue.
What you would like to accomplish:
The default notebook template should be updated to allow user specified service accounts instead of defaulting to the GCE Default SA.
If a pipeline were to fail in the future due to insufficient Shared VPC permissions, errors should either be logged within Vertex AI or the Dataflow pipeline itself. Currently, the pipeline fails with no indication to the root cause
Workaround:
The template could be run With the following modifications:
Assign the necessary roles (Compute Network User) to the Dataflow and worker service accounts as noted in [1] to the subnetwork (since Shared VPC being used)
Change the default template for the pipeline job to pass in the –dataflow-service-account parameter so that the dataflow could run with the correct permissions (By default, the template uses GCE Default Service Account and there is no option to specify the service account)
[1]https://cloud.google.com/dataflow/docs/guides/specifying-networks#shared