TODO:

Determine which acceptance criteria we can accomplish for 5.8 to align our forwarding deployment with the operator install-based auth used by other operators.

Possible todos: 

1. Add role_arn as an api field in the forwarder spec
2. Changes to operator install to alert users that we support sts flow for cloudwatch (and allow for a "default" ROLE_ARN to be entered?   There are many issues with this, including the fact that the text is specific to the "operator" install.  Proposal was put forth to use that role, if provided, to deploy a "default" forwarding instance.  This is not what OLM works.   Another options suggested is for a "post-install wizard", to ask if you'd like to create a forwarder, etc...
3. We need to create a console flow (template?) to allow for a forwarder to be created, with role, etc.   This is for any output that requires a role to be configured (cloudwatch)
4. According to James H., this is most important to align....  --> Modify the CLI flow to accommodate the CCO new feature (creating a secret directly from a credential request).  In this we will ask the user to apply the credReq directly to the cluster, rather than the instructions using ccoctl.  The CCO will reconcile this and create a secret in the namespace.  (we assume we own it then).   Once that secret is created (and they have set up cloud roles/permissions correctly), the CLO will project a service account token into the pod, used by each collector's api to authenticate with the cloud.
5. Degrade status (and provide message) when the role ARN is provided but CCO does not reconcile the CredentialRequest
6. Degrade status and message for missing secret, providing follow-up instructions to create the secret (via credReq).  

TESTS:

1. Ensure we degrade status when the role ARN is provided but CCO does not reconcile the CredentialRequest
2. Check for missing secret and provide follow-up instructions for creating