-
Notifications
You must be signed in to change notification settings - Fork 984
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 run_as_group to container security contexts attributes #414
Add run_as_group to container security contexts attributes #414
Conversation
…ate documentation and acceptance tests
66805d8
to
e2c43cd
Compare
Rebased on master. |
As already noted in #249, acceptance tests for this one are failing against kubernetes clusters where the feature is not available and enabled, such as GKE 1.12:
|
They do pass on minikube with kubernetes 1.14.1:
Not sure how to move this forward, maybe with a DiffSuppressFunc taking the availability of the feature and/or version of the cluster into account. |
I know that gke "alpha clusters" with more feature gates enabled can be created with https://www.terraform.io/docs/providers/google/r/container_cluster.html#enable_kubernetes_alpha |
I don't know if it is possible to directly inspect feature gates via the api. The only way know of to check them is via |
If @alexsomesan did you have something similar in mind when you created #378? |
@pdecat yes but its just a a string with the cli command. |
Indeed:
It may be acceptable to rely on that just for the acceptance tests. For real world setups, it could be left up to the user to know the limitations of its target cluster. |
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.
This looks great!
However, since most of our CI environments are not at 1.14 yet, it's going to be mostly going to be showing red.
To avoid that, I think we need some logic in the tests to skip if not running against a cluster that supports it.
Can you have a look at how difficult would that be to add?
@alexsomesan yeah, that's what we were discussing above. Checking the kubernetes cluster version in acceptance tests could be enough, and is certainly the easiest, as I don't believe the provider targets non standard configurations with alpha features. |
And what about implementing a Note: the only other place where server version is checked is for services updates. Edit: on second thought, this is probably more troubling to the user as it will think the configuration was accepted by the api server while it was actually silently discarded. |
…rnetes version is < 1.14.0
I've implemented the acceptance tests skipping option. With minikube 1.0.0 and kubernetes 1.14.1:
With GKE 1.12.7-gke.7:
|
This is a much better approach! I've discovered that some clusters don't use |
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.
LGTM. CI is green.
Regarding the CustomizeDiff question, I think we should be good without. Unless I misunderstood something, if we actually get values back from the API in the RunAsGroup
attribute, it means the feature is supported so we should be good to process. Do you mean to filter out user-provided values of run_as_group
when the server doesn't support it?
Yeah, that's what it would have resulted in. Bad idea IMO. |
yeah, I think we're safer like this, given that we don't have a deterministic way of telling whether the feature is on or not. |
…#414) Add run_as_group property to container and pod security contexts, update documentation and acceptance tests
As per @jhoblitt request, reviving this one.
Needs rebase.
For reference, the
RunAsGroup
feature has been promoted to beta and enabled by default in kubernetes 1.14.