Improve secret handling of credentials

[mjnagel]

Is your feature request related to a problem?

Currently you have two routes for storing credentials in a secret:

• Deploy the operator (which also creates the namespace for the operator), create a secret, and roll the operator pod so that it grabs its env from the secret
• Pre-create the namespace and secret then deploy the operator

The issues I see with this:

• The secret has to exist before the operator, but the secret is really not for the operator, its for the "instance" - this seems clunky
• There is no support for multiple instances (this might not be a desired use case which is OK) or a single instance with a differently named secret
• Changing credentials will always require an operator restart rather than an update to the ConsoleDefender spec which is then handled by the operator

Describe the solution you'd like

Provide a way that users can specify a secret with the credentials in the ConsoleDefender spec (and the others as necessary). Example implementation for the spec:

apiVersion: pcc.paloaltonetworks.com/v1alpha1
kind: ConsoleDefender
metadata:
  name: pcc-consoleplusdefender
  namespace: twistlock
spec:
  credentials:
    secret: my-secret-name

Then the operator would lookup a certain set of expected keys from that secret and use them for user/pass/license/token.

Describe alternatives you've considered

There are a number of ways to implement this. Another possibility that I have seen in other operators is something along these lines:

apiVersion: pcc.paloaltonetworks.com/v1alpha1
kind: ConsoleDefender
metadata:
  name: pcc-consoleplusdefender
  namespace: twistlock
spec:
  credentials:
    license: secret:my-secret-name:licensekey
    username: secret:my-secret-name:userkey
    ...

In this implementation the operator would look for secret: and then split the remainder of the value into name of secret : key in secret. This would keep the existing spec but expand the options for passing in values.

Additional context

Without this option a user has to choose between pre-creating the secret and having it stored in the operator or providing the values plaintext in the spec (which is obviously not ideal and doesn't currently work).