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

add kubeadmin login test #21733

Merged
merged 1 commit into from
Jan 16, 2019

Conversation

sallyom
Copy link
Contributor

@sallyom sallyom commented Jan 6, 2019

@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.

)

var _ = g.Describe("[Conformance] The bootstrap user", func() {
defer g.GinkgoRecover()
Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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

Copy link
Contributor Author

@sallyom sallyom Jan 11, 2019

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.

@sallyom sallyom force-pushed the add-smoke-4-test branch 2 times, most recently from 567f5bd to 41f4a5b Compare January 11, 2019 22:45
@openshift-ci-robot openshift-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Jan 11, 2019
@openshift-ci-robot openshift-ci-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Jan 11, 2019
@sallyom sallyom force-pushed the add-smoke-4-test branch 3 times, most recently from 59b0858 to 1f6b704 Compare January 15, 2019 16:05
@sallyom
Copy link
Contributor Author

sallyom commented Jan 15, 2019

/retest

})

func generatePassword() (string, []byte, error) {
password := uuid.NewRandom().String()
Copy link
Contributor

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.

Copy link
Contributor Author

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)
Copy link
Contributor

Choose a reason for hiding this comment

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

do not log password

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok, done

@enj
Copy link
Contributor

enj commented Jan 16, 2019

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Jan 16, 2019
@openshift-ci-robot
Copy link

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 16, 2019
@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

1 similar comment
@openshift-bot
Copy link
Contributor

/retest

Please review the full test history for this PR and help us cut down flakes.

@openshift openshift deleted a comment from openshift-bot Jan 16, 2019
@sallyom
Copy link
Contributor Author

sallyom commented Jan 16, 2019

/test e2e-aws-serial

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants