[WIP] Introduce kubeapiserver.config.k8s.io/v1 and use standard method for parsing encryption config file#63032
[WIP] Introduce kubeapiserver.config.k8s.io/v1 and use standard method for parsing encryption config file#63032php-coder wants to merge 40 commits intokubernetes:masterfrom
Conversation
|
/sig auth At this time it doesn't work yet as compilation fails with: @liggitt @smarterclayton We need to move encryption configuration somewhere, but I'm not sure where its place. If we want to use How we can handle this? |
There was a problem hiding this comment.
@liggitt This type looks suspicious. Did we decide some time ago to always use integers with a fixed size in APIs, do we?
There was a problem hiding this comment.
the field in the external type should be a fixed size int, yes
There was a problem hiding this comment.
I decided to make some functions private, it doesn't relate to my change. Let me know if it's inappropriate change at all or if I should submit it separately.
There was a problem hiding this comment.
there's no real reason to make these private, so let's revert this change.
There was a problem hiding this comment.
@liggitt Do we have a requirement to fully support old format of the config file? Perhaps we should show a warning in this case?
There was a problem hiding this comment.
I assume that no, we don't have such requirement.
The documentation says to use Because we were using a non-standard load that ignored version, this wasn't caught before. I'd actually be in favor of promoting the config version to |
@liggitt Do I understand you correctly, that we should do this promotion before moving encryption config there? In other words, we have one more dependency for promoting encryption config to beta. I'll be able to prepare and submit PR next week. |
Done: #63304 |
ced4b1d to
d097747
Compare
There was a problem hiding this comment.
I'm not sure about this change because v1 has one type and v1alpha1 has others, in other words, these aren't different versions of the same API but different APIs in fact.
There was a problem hiding this comment.
The admissionregistration seems to do something similar where different versions of the API hold different object.
https://github.com/kubernetes/api/blob/kubernetes-1.10.2/admissionregistration/v1alpha1/register.go#L45-L48
https://github.com/kubernetes/api/blob/kubernetes-1.10.2/admissionregistration/v1beta1/register.go#L45-L50
Any apimachinery folk care to comment here? It looks fine to me.
There was a problem hiding this comment.
I've just casted int32 to int here but let me know if there is a better way or perhaps we should use int32 everywhere.
There was a problem hiding this comment.
Do we have a better way for parsing YAML? I couldn't find a way of getting a scheme.
CC @sttts
There was a problem hiding this comment.
This is what we do for the audit API policy file
There was a problem hiding this comment.
Now we don't need these checks as they will be performed by deserializer.
There was a problem hiding this comment.
This PR makes the old configs unusable. If we have to be backward compatible and you know how to handle such cases, please, share this knowledge with me or, at least, point me to the right direction. Thanks!
There was a problem hiding this comment.
Definitely needs a release note.
We could try to parse out the kind and apiVersion beforehand, then conditionally use the old parsing logic. Don't know how much work that is.
There was a problem hiding this comment.
We can register the types under the legacy core group in the scheme used for decoding. Why is that no option?
There was a problem hiding this comment.
Probably this was just never considered. Would that mean there would be two different API groups for one functionality? Could the legacy one ever be deprecated? Should that be done at a different time than when promoting from alpha to unfortunate stable?
There was a problem hiding this comment.
yes, same types, multiple groups. Technically possible.
Good question about deprecation. Formally we will probably have to stick with this forever.
837aaaf to
0384b7e
Compare
0384b7e to
d1868f5
Compare
…/apis/webhookadmission/register.go
78cccd0 to
94fb043
Compare
|
@php-coder: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
I've fixed this by adding At this moment, I faced with another verify import violation: Not sure how to fix it, perhaps, I need to relax this check. |
|
@liggitt @sttts Would the following patch help moving this PR forward? I have this plus the commits from this PR squashed and rebased on the current (~week old) master in https://github.com/stlaz/kubernetes/tree/slava_encryptconfig. I believe @php-coder won't have much time to carry on with his work on this one. From ceae7ac28d3a29d064aaccad2c6c59e23b7937d7 Mon Sep 17 00:00:00 2001
From: Stanislav Laznicka <slaznick@redhat.com>
Date: Mon, 30 Jul 2018 09:22:04 +0200
Subject: [PATCH] Loosen ./vendor/k8s.io/apiserver/ import verification
Loosen ./vendor/k8s.io/apiserver/ import verification so that it allows
imports from k8s.io/pkg/kubeapiserver so that it can use the
EncryptConfiguration objects
---
hack/import-restrictions.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/hack/import-restrictions.yaml b/hack/import-restrictions.yaml
index f9749300a8..f5194bb839 100644
--- a/hack/import-restrictions.yaml
+++ b/hack/import-restrictions.yaml
@@ -79,6 +79,7 @@
- k8s.io/apiserver
- k8s.io/client-go
- k8s.io/kube-openapi
+ - k8s.io/kubernetes/pkg/kubeapiserver
- baseImportPath: "./vendor/k8s.io/metrics/"
allowedImports:
--
2.18.0 |
|
This proposal is probably a bit related to this PR: kubernetes/community#2354 |
|
@luxas I finally got to read the design and compare it to this PR. If I understand the KEP correctly, the |
Yes, eventually, but that's not a near-term goal for that KEP specifically.
If this is generic apiserver code I guess it can live in |
|
This PR originally implemented the changes as a part of |
|
@luxas I just went through the code again, we could probably really go and contain this change just for |
|
Superseded by #67383 /close |
|
@php-coder: Closing this PR. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
What this PR does / why we need it:
This PR reworks handling of the configuration file for encryption at rest. Now it uses a standard approach for parsing and also it supports versioning.
Which issue(s) this PR fixes:
Fixes #61599