-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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 kubeadmin login test #21733
add kubeadmin login test #21733
Conversation
1a0c6c7
to
34fe7a3
Compare
) | ||
|
||
var _ = g.Describe("[Conformance] The bootstrap user", func() { | ||
defer g.GinkgoRecover() |
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.
@smarterclayton It's unclear to me what the exact label for this should be. Conformance
ok?
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.
Depends on what this is supposed to test. You can't couple an extended test to the installer artifacts (e2e tests have to run against anyone's cluster). Mo owns testing that we can set / update a bootstrap user on a cluster, so at that point you're more about establishing that a newly created cluster has a bootstrap user. However, not all users are going to run extended against a cluster with a bootstrap user, so we'd have to make the test conditional on that behavior.
- A test that verifies the installer itself creates a bootstrap user would belong to the installer and be in that repo.
- A test that verifies that a conformant openshift cluster can have a bootstrap user and exercises the secret creation paths and verifies oauth logins work would be here, but would not be part of the conformance suite (this is what I alluded to mo owning)
I think you're trying to build more of the former rather than the latter - since you're trying to verify that the installer correctly sets up the password AND that the password is useful, so this really belongs in the installer test suite.
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.
We also want to confirm that what has to happen via authentication/osin/oauthconfig for token-generation is not broken.
We could go back to my original plan of checking that both are kosher in the cluster-launch-installer-* templates, by logging in/switching back to system:admin context.
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.
verify that the installer correctly sets up the password AND that the password is useful
- the installer already 'tests' that the password is created, by spitting it out at the end (and errors if not read, in cmd/openshift-install/create.go).
- to test that it's useful, have to go through oauthserver. I still don't see how that test belongs in the installer. It requires an unsupportedConfigOverrides oauthConfig section in kubeAPIServerOperatorConfig patched, etc. Only way to test that that completed is to run
oc login
with kubeadmin
.
this really belongs in the installer test suite.
AFAIK there isn't an installer test suite atm? There was a smoke tests suite but it's not currently run/they're outdated/tectonic references still. I can look at updating those, but that might take awhile, and the auth team needs assurance now that upcoming changes don't break kube:admin.
A test that verifies that a conformant openshift cluster can have a bootstrap user and exercises the secret creation paths and verifies oauth logins work would be here
Yes, this! So I need to make this extended test conditional on clusters that have the bootstrap kubeadmin password (ie, any cluster created with openshift/installer)? Or, easiest way (for now) is to put this check in the cluster-launch-installer-* CI templates, for all jobs running against a cluster launched w/ openshift/installer like so: openshift/release#2440
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.
@enj mentioned I can create or apply new data to the kubeadmin secret in the extended test that conforms to the pw requirements, then check for kubeadmin user login, since every 4.0 cluster has the ability to create kubeadmin user, I'll go with that.
567f5bd
to
41f4a5b
Compare
41f4a5b
to
bf1f453
Compare
59b0858
to
1f6b704
Compare
/retest |
fb75c29
to
9fce793
Compare
}) | ||
|
||
func generatePassword() (string, []byte, error) { | ||
password := uuid.NewRandom().String() |
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.
Use Random256BitsString
. UUIDs are not valid sources of random data.
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.
ok, done
kubeadminSecret := generateSecret(passwordHash) | ||
_, _, err = resourceapply.ApplySecret(oc.AsAdmin().KubeClient().CoreV1(), recorder, kubeadminSecret) | ||
o.Expect(err).NotTo(o.HaveOccurred()) | ||
e2e.Logf("logging in as kubeadmin user with password: %s", password) |
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.
do not log password
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.
ok, done
9fce793
to
220d906
Compare
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: enj, sallyom The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/retest Please review the full test history for this PR and help us cut down flakes. |
1 similar comment
/retest Please review the full test history for this PR and help us cut down flakes. |
/test e2e-aws-serial |
@enj @smarterclayton test for kubeadmin login.
this test generates and applies a new kubeadmin secret to test login, then restores to original if it existed, or deletes it if it did not.