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

Restrict node access to cluster metadata service #166

Closed

Conversation

dmyerscough
Copy link

I was recently had my private GKE cluster pen test and one of the issues that were reported by this test was POD's had access the metadata service which exposes sensitive data:-

# curl -H 'Metadata-Flavor: Google' 'http://metadata.google.internal/computeMetadata/v1/instance/attributes/kube-env'
ALLOCATE_NODE_CIDRS: "true"                                                                                                                                            API_SERVER_TEST_LOG_LEVEL: --v=3
...
...
KUBE_PROXY_TOKEN: h9gjoyXnyaB2MDnBeOPmJG3OEJ0zS7GKXtU-9xMJRTw=
KUBELET_CERT: XXXXXXXXXX
KUBELET_KEY: XXXXXXXXX
KUBERNETES_MASTER: "false"
KUBERNETES_MASTER_NAME: 10.17.5.2
LOGGING_DESTINATION: gcp
...
...

By default, GKE clusters expose "UNSPECIFIED". However, you can switch this off by setting node_metadata to "SECURE".

$ curl -H 'Metadata-Flavor: Google' 'http://metadata.google.internal/computeMetadata/v1/instance/attributes/kube-env'
This metadata endpoint is concealed.

$ curl -H 'Metadata-Flavor: Google' 'http://metadata.google.internal/computeMetadata/v1/instance/attributes/disable-legacy-endpoints'
false

This PR will allow the clusters to move along as normal but will give anyone the ability to shut off metadata service by specifying "SECURE" instead of the default "UNSPECIFIED".

I have tested this on our internal zonal cluster and it worked as expected.

@dmyerscough
Copy link
Author

@morgante @aaron-lane would you be able to review the above change?

Copy link
Contributor

@morgante morgante left a comment

Choose a reason for hiding this comment

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

Thanks for the contribution. Instead of directly editing the files, can you update the autogen templates (https://github.com/terraform-google-modules/terraform-google-kubernetes-engine/blob/master/autogen/cluster_regional.tf#L104) and then generate the modules from it?

@dmyerscough
Copy link
Author

Yeah, I can update that shortly.

@aaron-lane aaron-lane requested a review from morgante June 14, 2019 14:21
@aaron-lane aaron-lane added the enhancement New feature or request label Jun 14, 2019
Copy link
Contributor

@morgante morgante left a comment

Choose a reason for hiding this comment

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

Thanks for the contribution! Looks like workload_metadata_config is only available in beta so we will have to wait for the beta submodules with #124.

@aaron-lane
Copy link
Contributor

@dmyerscough #124 has been merged. There are now submodules specifically for public and private clusters with beta features enabled, and templating logic to support that. Are you available to update this branch accordingly?

@aaron-lane
Copy link
Contributor

Superseded by #203.

@aaron-lane aaron-lane closed this Jul 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants