Status Update
No update yet.
Comments
ow...@google.com
ow...@google.com
Today I spent some time looking into this again, because I noticed at some point in the past year OpenBSD's DHCP client stopped working with GCE's DHCP server.
Just for posterity, here's a current DHCP client/server exchange:
16:25:26.187577 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
10.240.120.1.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 42:01:0a:f0:78:01, length 300, xid 0xdf529822, Flags [none] (0x0000)
Client-Ethernet-Address 42:01:0a:f0:78:01
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Hostname Option 12, length 8: "xxxxxxxx"
Requested-IP Option 50, length 4: 10.240.120.1
Parameter-Request Option 55, length 8:
Subnet-Mask, BR, Time-Zone, Classless-Static-Route
Default-Gateway, Domain-Name, Domain-Name-Server, Hostname
Client-ID Option 61, length 7: ether 42:01:0a:f0:78:01
16:25:26.188125 IP (tos 0x0, ttl 1, id 0, offset 0, flags [none], proto UDP (17), length 471)
169.254.169.254.67 > 10.240.120.1.68: [udp sum ok] BOOTP/DHCP, Reply, length 443, xid 0xdf529822, Flags [none] (0x0000)
Your-IP 10.240.120.1
Server-IP 10.240.0.1
Gateway-IP 10.240.0.1
Client-Ethernet-Address 42:01:0a:f0:78:01
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 169.254.169.254
Domain-Name-Server Option 6, length 8: 169.254.169.254,10.240.0.1
Lease-Time Option 51, length 4: 4294967295
Domain-Name Option 15, length 30: "c.xxxxxxxxxxxxxxxxxx.internal."
T119 Option 119, length 63: 1.99.18.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.X.8.105.110.116.101.114.110.97.108.0.12.51.55.52.49.50.49.55.50.48.50.52.49.6.103.111.111.103.108.101.8.105.110.116.101.114.110.97.108.0.192.44
Subnet-Mask Option 1, length 4: 255.255.255.255
Default-Gateway Option 3, length 4: 10.240.0.1
Classless-Static-Route Option 121, length 14: (
MTU Option 26, length 2: 1460
Hostname Option 12, length 40: "xxxxxxxxxx.c.xxxxxxxxxxxxxxxxxx.internal"
NTP Option 42, length 4: 169.254.169.254
The particularly relevant details:
- RFC 3442 specifies that a Classless-Static-Route entry like "
- For DHCP clients that don't support RFC 3442, if Subnet-Mask == 255.255.255.255, then the DHCP client needs to assume the Default-Gateway is directly routable. (This isn't specified by any RFCs as far as I can tell though.)
The regression was because:
- ISC DHCP doesn't implement Classless-Static-Route support (as far as I can tell), but it does implement the Subnet-Mask == 255.255.255.255 hack for Default-Gateway.
- When I first modified OpenBSD dhclient to work with GCE, dhclient wasn't seeing any Classless-Static-Route options in the server response. Since ISC DHCP's behavior was undocumented, I simply matched the implementation exactly by only extending the Default-Gateway processing.
- Some point within the last year, OpenBSD dhclient started seeing Classless-Static-Route options from the server*. OpenBSD's Classless-Static-Route support didn't implement the "local route" behavior (instead it skipped over those routes as permitted by the RFC), and the presence of the Classless-Static-Route option precludes handling of the Default-Gateway option.
* It's unclear to me why. It looks like OpenBSD dhclient has supported Classless-Static-Route for more than a year, so I suspect GCE's DHCP server must have changed since then to start using this option.
Finally, the fix was to implement "local subnet route" support in OpenBSD dhclient:
ow...@google.com
I apologize, you are correct, I mean
I'm going to change this Request type to Feature Request and create an internal Feature Request to create the function to disable/togle SSH access when required via API/UI.
Please keep in mind that this Feature Request has to be analyzed and considered by the product team and I can't provide you ETA for it to be delivered.
However, you can keep track of the status by following this thread.
As of now, the SSH access is allowed/blocked by firewall rules that accept SSH traffic on port 22.
Since I can't provide you an ETA for your requested feature to be delivered, as a workaround I suggest you checking
This way you can remove all rules on your tcp:22 and editing rules that have 22 in range like tcp:1-65535. to remove it from the range.
st...@gmail.com
Is it relevant for GKE nodes since it is written for GCE?
Do you have any updates so far?
BR,
Stilian Stoilov
ma...@google.com
Hello,
According to the
Please note that the Issue Tracker is primarily meant for reporting bugs and requesting new features. If you have any additional issues or concerns, please don’t hesitate to create a new thread on the
Thanks and Regards,
Mahaboob Subhani
Google Cloud Support
Description
We need to comply with a HIPAA regulation that requires us to run vulnerability and virus scanning on all exposed running compute instances. We'd like to treat nodes as a "black box" to get around this requirement since COS is already scanned for vulnerabilities and would like to have it configured via GKE.
What you expected to happen:
Able to easily disable all SSH access to the underlying GCE instances.
Steps to reproduce:
Create a GKE cluster.
Other information (workarounds you have tried, documentation consulted, etc):
HIPAA 45 CFR 164.308(a)(8)
In accordance with HIPAA 45 CFR 164.306 and 164.308(a)(5)(ii)(B) a covered entity or business associate must protect against any reasonably anticipated threats or hazards to the security or integrity of PHI. This includes implementing procedures for guarding against, detecting, and reporting malicious software.