Complete Epics
This section includes Jira cards that are linked to an Epic, but the Epic itself is not linked to any Feature. These epics were completed when this image was assembled
Goal: as a cluster admin, I want to registry credentials across a cluster so that teams can use the credentials for importing images and in builds (pull/push) without having to configure secrets within every project.
Red Hat registry authorization rules have changed which is not required when images are pulled from registry.access.redhat.com. Given that new Red Hat images are only available via registry.redhat.io which requires authentication, users are not able to just pull and use (deploy or use with builds) OpenShift images from the Red Hat registry in their namespaces like they did before and have to ask a cluster admin to import them into the openshift namespace. The openshift namespace contains a secret called samples-registry-credentials with the Red Hat registry credentials which is created by the samples-operator. That facilitates image stream import in that particular project but nothing more.
MCO is able to put the installer pull secret and any user specified credentials on the nodes. Taking advantage of that, Build and ImageStream controllers could leverage these credentials to handle the complete set of desired scenarios.
A developer should be able to pull images from either the Red Hat registry or users’ specific registries that require credentials (where they have provided those credentials to the MCO) without any extra steps (e.g. configuring extra secrets). The targeted scenarios in this epic are:
- Import images into imagestream
- Image registry pull-through
- Build image pull.
When the above works, users should be able to successfully run the following commands on a vanilla OpenShift 4 cluster:
- oc new-build nginx registry.redhat.io/rhel8/nginx~https://git-url
- oc new-app nginx registry.redhat.io/rhel8/nginx~https://git-url
- oc import-image registry.redhat.io/rhel8/nginx-114 --confirm
Problem: accessing Red Hat registry content (even images that are part of OpenShift) is cumbersome, and requires each user to acquire Red Hat registry credentials and perform a number of cumbersome steps to configure the credential in each namespace. Alternatively, they have to ask the cluster admin to the same for each namespace and skip acquiring their own credentials. The same problem applies to access other private registries.
Why is this important: to allow OpenShift users to consume Red Hat registry content on OpenShift in a self-service manner and simplify accessing private image registries.
Dependencies (internal and external):
- MCO - puts credentials on nodes the same way that it does it for RHCC credentials
Prioritized epics + deliverables (in scope / not in scope):
- Add node credentials to builds as pull/push secret
- Add node credentials to imagestreams for pulling images
- End-to-end docs for configuring private registries credentials (using MCO)
Estimate (XS, S, M, L, XL, XXL): M
Previous Work:
Customers:
- OpenShift Dedicated has this issue in both v3 and v4. The permissions model in OSD does not allow a customer to read secrets in any openshift-* namespaces. Therefore the workaround of having the cluster-admin copy the secret manually into namespaces will not work on OSD. The 3 example commands (oc new-build / oc new-app / oc import-image) all fail with an “unauthorized” response from registry.redhat.io in OSD 4.x. In OSD 3, we solve this issue using a config-loop which creates a systemd service which runs this script. Again, we have no solution for this in 4.x and 3.x uses said workaround.
- ARO (v3) puts the pull secret in the openshift namespace and on each node for docker to access. ARO v4 does not yet exist, and would likely leverage any solution delivered in the product.
Open questions:
- Is this day-1? If so, are we going to reuse the pullsecret from install config?
Yes, reusing the same pull secrets from the install config, provided that’s all needed for using images from Red Hat registry with imagestreams and builds
- Day-2: where is the additional pull secret living? Configmap? Which ns? There is no “additional pull secret” - additional secrets are added by updating the master pull secret in openshift-config
- Day-1-2: are this crio pull secrets? Right now the MCO lands the pull secret to path: "/var/lib/kubelet/config.json", these are the crio pull secrets.
- Do ARO or OSD do anything special wrt pull secrets? - Answered in the “Customers” section within this epic.
User Story
As an OpenShift user
I want the node credentials to be available for all builds
So that builds can always pull from registry.redhat.io
And other registries which require a pull secret
Acceptance Criteria
- Build pod always mounts pull secrets that are available on the node
- Pull secret from node is used when pulling images from authenticated registries, such as registry.redhat.io
- Node credentials are used in addition to user-provided credentials. Order of precedence:
- User-provided pull secrets (from build controller)
- Pull secrets from service accounts (from build controller)
- Node credentials - to be mounted and merged in
Launch Checklist
Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated
Notes
Related to using mirrors in builds.
It is possible that the user-provided creds and node creds can have overlapping registries.
We should submit an enhancement proposal - done.
Code needs to comment where we are mounting items from the host for future unprivileged/secured builds.
In a follow-up story we can add the ability to opt in/out of this feature.
User Story
As an OpenShift user
I want the node credentials to be used in imagestream pull-through
So that I can import images from registry.redhat.io
And other registries which require a pull secret
And cache the content on the internal registry
Acceptance Criteria
- Image registry operator mounts the node pull secret into the image registry container
- Image registry merges secrets during pull-through, with following precedence:
- dockercfg secrets that exist in the image stream's namespace
- Node credentials
- Test cases
- Import an image from registry.redhat.io without adding a pull secret in the namespace. Must use the --reference-policy=local flag to enable pull-through.
- Import uses a pull secret that exists only in the image stream's namespace (regression test)
Launch Checklist
Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated
Notes
Existing issues with multiple creds for same registry are out of scope.
Potentially reuse code in DEVEXP-423 via github.com/openshift/runtime-utils repo or library-go.
(docker client used to be shared in origin).
User Story
As an OpenShift user
I want the node credentials to be used in imagestream import
So that I can import images from registry.redhat.io
And other registries which require a pull secret
Acceptance Criteria
- Imagestream import mounts node pull secrets and uses them in imagestream import
- Node credentials are merged with secrets used during import, with following precedence:
- dockercfg secrets that exist in the namespace
- Node credentials
- Test case - import an image from registry.redhat.io without adding a pull secret in the namespace. Does not need to be a pull-through imagestream.
Launch Checklist
Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated
Notes
Needs input from the node and apiserver teams.
Existing issues with multiple creds for same registry are out of scope.
Potentially reuse code in DEVEXP-423 via github.com/openshift/runtime-utils repo.
Goal: Rebase to Kubernetes 1.18
Problem: DevExp components include control plane operators. These should be kept up with the upstream release to ensure these do not fall more than 1 release behind.
Why is this important: Rebasing reduces tech debt in future releases.
Dependencies (internal and external):
- Apiserver - kubernetes 1.18 rebase
- openshift/api and openshift/client-go - k8s rebase (wire in context)
Prioritized epics + deliverables (in scope / not in scope):
DEVEXP-553Rebase openshift-controller-manager on k8s 1.18DEVEXP-554Rebase openshift-controller-manager-operator on k8s 1.18DEVEXP-556Rebase image registry operator on Kubernetes 1.18DEVEXP-555Rebase image registry on Kubernetes 1.18DEVEXP-557Rebase samples operator on k8s 1.18DEVEXP-558Rebase openshift/builder on k8s 1.18
Estimate (XS, S, M, L, XL, XXL): M
Previous Work:
DEVEXP-475(1.17 rebase)
Customers:
Open questions:
User Story
As a developer using OpenShift
I want the image registry to use k8s 1.18 libraries
So that the image registry can take advantage of the latest Kubernetes features.
Acceptance Criteria
- Image registry works with k8s 1.18 libraries
- Image registry capabilities work on k8s 1.18 clusters (image pull, image push, etc.)
Launch Checklist
Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated
Notes
Add pertinent notes here:
- Enhancement proposal link
- Previous product docs
- Best practices
- Known issues
Guiding Questions
User Story
- Is this intended for an administrator, application developer, or other type of OpenShift user?
- What experience level is this intended for? New, experienced, etc.?
- Why is this story important? What problems does this solve? What benefit(s) will the customer experience?
- Is this part of a larger epic or initiative? If so, ensure that the story is linked to the appropriate epic and/or initiative.
Acceptance Criteria
- How should a customer use and/or configure the feature?
- Are there any prerequisites for using/enabling the feature?
Notes
- Is this a new feature, or an enhancement of an existing feature? If the latter, list the feature and docs reference.
- Are there any new terms, abbreviations, or commands introduced with this story? Ex: a new command line argument, a new custom resource.
- Are there any recommended best practices when using this feature?
- On feature completion, are there any known issues that customers should be aware of?
User Story
As a developer using OpenShift
I want the image registry operator to use k8s 1.18 libraries
So that the image registry operator can take advantage of the latest Kubernetes features.
Acceptance Criteria
- Image registry operator works with k8s 1.18 libraries
- Image registry is deployed on k8s 1.18 clusters
Launch Checklist
Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated
Notes
Add pertinent notes here:
- Enhancement proposal link
- Previous product docs
- Best practices
- Known issues
Guiding Questions
User Story
- Is this intended for an administrator, application developer, or other type of OpenShift user?
- What experience level is this intended for? New, experienced, etc.?
- Why is this story important? What problems does this solve? What benefit(s) will the customer experience?
- Is this part of a larger epic or initiative? If so, ensure that the story is linked to the appropriate epic and/or initiative.
Acceptance Criteria
- How should a customer use and/or configure the feature?
- Are there any prerequisites for using/enabling the feature?
Notes
- Is this a new feature, or an enhancement of an existing feature? If the latter, list the feature and docs reference.
- Are there any new terms, abbreviations, or commands introduced with this story? Ex: a new command line argument, a new custom resource.
- Are there any recommended best practices when using this feature?
- On feature completion, are there any known issues that customers should be aware of?
User Story
As a developer using OpenShift
I want the the samples operator to use k8s 1.18 libraries
So that the samples operator s can take advantage of the latest Kubernetes features.
Acceptance Criteria
- Samples operator can work with k8s 1.18 libraries
- Sample imagestreams and templates install on k8s 1.18 clusters
Launch Checklist
Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated
Notes
Add pertinent notes here:
- Enhancement proposal link
- Previous product docs
- Best practices
- Known issues
Guiding Questions
User Story
- Is this intended for an administrator, application developer, or other type of OpenShift user?
- What experience level is this intended for? New, experienced, etc.?
- Why is this story important? What problems does this solve? What benefit(s) will the customer experience?
- Is this part of a larger epic or initiative? If so, ensure that the story is linked to the appropriate epic and/or initiative.
Acceptance Criteria
- How should a customer use and/or configure the feature?
- Are there any prerequisites for using/enabling the feature?
Notes
- Is this a new feature, or an enhancement of an existing feature? If the latter, list the feature and docs reference.
- Are there any new terms, abbreviations, or commands introduced with this story? Ex: a new command line argument, a new custom resource.
- Are there any recommended best practices when using this feature?
- On feature completion, are there any known issues that customers should be aware of?
User Story
As a developer using OpenShift
I want the builder image to use k8s 1.18 libraries
So that builds can take advantage of the latest Kubernetes features.
Acceptance Criteria
- Builds can work with k8s 1.18 libraries
Launch Checklist
Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated
Notes
Add pertinent notes here:
- Enhancement proposal link
- Previous product docs
- Best practices
- Known issues
Guiding Questions
User Story
- Is this intended for an administrator, application developer, or other type of OpenShift user?
- What experience level is this intended for? New, experienced, etc.?
- Why is this story important? What problems does this solve? What benefit(s) will the customer experience?
- Is this part of a larger epic or initiative? If so, ensure that the story is linked to the appropriate epic and/or initiative.
Acceptance Criteria
- How should a customer use and/or configure the feature?
- Are there any prerequisites for using/enabling the feature?
Notes
- Is this a new feature, or an enhancement of an existing feature? If the latter, list the feature and docs reference.
- Are there any new terms, abbreviations, or commands introduced with this story? Ex: a new command line argument, a new custom resource.
- Are there any recommended best practices when using this feature?
- On feature completion, are there any known issues that customers should be aware of?