cloud credentials secret "noobaa-aws-cloud-creds-secret" is not ready yet
Closed this issue · 7 comments
OCP Version : 4.8.15
OCS Version: 4.8.3
Deployed OCP with CCO / STS.
Installed OpenShift Container Storage Operator without any issue. Created a storage cluster via the UI.
ocs-storagecluster-cephcluster deployed fine and is in ready state.
noobaa is in Configuring state.
Conditions show the following message:
cloud credentials secret "noobaa-aws-cloud-creds-secret" is not ready yet
there isn't any secret with that name.
I cannot use IAM Account Key/Secret in my setup.
I am expecting OCS to support CCO.
When installing the cluster with STS, CCO is not processing CredentialsRequests from within the cluster. The user is responsible for taking a CredentialsRequest with the required list of permissions and creating the IAM Role and the eventual Secret holding the credentials. There is a ccoctl utility that can help take a CredentialsRequest and generate the IAM Role and Secret (which you can then apply to the cluster).
Thanks for the quick response.
I have used ccoctl the create the base role needed for the install of OCP
Is there documentation on what CredentialsRequests is needed for noobaa (ie from OCS), and how to generate it?
A user is not expected to generate CredentialsRequest objects. The operator/component team would produce one as they know best which permissions are needed.
Each component typically includes a CredentialsRequest as part of the various k8s resources that are applied during installation. If you look at the output of oc get -A credentialsrequests you should see a list of all of the CredentialsRequests installed on the cluster. If noobaa does in fact rely on CredentialsRequests CRs, then one of those in the list (maybe more than one if noobaa has different permissions requirements for different clouds) will have been applied as part of the noobaa installation.
If noobaa does in fact create/apply a CredentialsRequest to the cluster, you'll see an object that looks something like https://github.com/openshift/cloud-credential-operator/blob/master/manifests/05-iam-ro-credentialsrequest.yaml
Whether noobaa is ready or not to accept using IAM Roles instead of static access_key/secret_key for authentication against AWS is something that team would know. But if the core operator hasn't been updated for this possibility, then they might have suggestions on next steps.
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
/remove-lifecycle stale
Rotten issues close after 30d of inactivity.
Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.
/close
@openshift-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue by commenting
/reopen.
Mark the issue as fresh by commenting/remove-lifecycle rotten.
Exclude this issue from closing again by commenting/lifecycle frozen./close
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.