update documentation (#318)

README.md

@@ -54,6 +54,9 @@ Our default standards in Polaris are rather high, so don’t be surprised if you
 
 Polaris can be run as an admission controller that acts as a validating webhook. This accepts the same configuration as the dashboard, and can run the same validations. This webhook will reject any workloads that trigger a danger-level check. This is indicative of the greater goal of Polaris, not just to encourage better configuration through dashboard visibility, but to actually enforce it with this webhook. Polaris will not fix your workloads, only block them. 
 
+The webhook only supports a fixed set of controller types. You can see the
+[list of supported controllers here](https://github.com/FairwindsOps/polaris/blob/master/cmd/polaris/webhook.go#L40)
+
 Unfortunately we have not found a way to display warnings as part of `kubectl` output unless we are rejecting a workload altogether. That means that any checks with a severity of `warning` will still pass webhook validation, and the only evidence of that warning will either be in the Polaris dashboard or the Polaris webhook logs.
 
 ## CLI

ROADMAP.md

@@ -5,55 +5,21 @@ as well as the project's overall functionality.
 If you have ideas for a new check, or for new Polaris features,
 you can submit a pull request for this file, or open an issue in GitHub.
 
-## Q3 2019
-Below is a list of work we plan to get done this quarter. Some more details can be found under
-[Future Work](#future_work), or
-[in the milestone](https://github.com/FairwindsOps/polaris/milestone/1)
-* Rule exceptions - we'd like to provide a way of overriding Polaris checks on individual controllers, e.g. through annotations
-* More controller types - we plan to implement checks for more than just deployments
-* Image repo checks - we plan to provide a check that ensures all repos conform to a set of user-defined patterns
-* OPA integration (investigate only) - we plan to investigate the potential use of OPA to let users define custom Polaris checks
-
-## Future Work
-### Validating Webhook
-The validating webhook rejects incoming workloads if they cause `error`-level
-issues, as defined by the Polaris configuration.
-
-The webhook server is currently functional, but largely untested. Because
-the validating webhook has the potential to cause headaches for users,
-we have marked it as `beta` for now.
-
-We will continue to gather feedback here and will move the webhook out of `beta`
-when we feel it's ready.
-
-#### TODO
-* Pass `warning`-level messages back to `kubectl` if possible (may require changes
-to core k8s or `kubectl`)
-
-### Ability to override checks
-We plan to add the ability to override Polaris checks for particular namespaces
-and workloads. This may be something that is set in the Polaris configuration,
-or an annotation that can be added to the resource definition.
-
-This is important, as certain workloads have good reason to skip particular Polaris
-checks - for instance, the `dns-controller` deployment in `kube-system` needs to have
-the host network configured.
+## Check non-controllers
+We would like to implement checks for non-controller types, such as:
+* Ingresses
+* Services
+* RBAC roles/bindings
 
-### Images Registries Check
-We'd like to allow users to restrict images to a list of allowed/disallowed registries.
-We'll likely allow patterns, e.g. `*.dkr.ecr.*.amazonaws.com`
+## Expand list of checks
+We'd like to increase our library of checks. Not all checks need to be enabled by default,
+so anything that would be useful across different organizations is worth checking in.
 
-### New controller types
-Currently we only look at Deployments. We plan to also validate these types of controllers:
-* StatefulSet
-* DaemonSet
-* Job
-* CronJob
-* ReplicaSet
+## Support more controllers in the validating webhook
+Currently the webhook only checks for a fixed set of controllers.
 
-### Check non-controllers
-We would like to implement checks for non-controller types, such as:
-* Ingress
-* Service
-* Secret
+While we can't listen for _all_ possible controller types, we can block Pods that violate policy.
+We've chosen not to do this for now, because it could prevent existing controllers from scaling.
 
+However, there may be a way to check for the owner's age, in order to determine if it's a new
+controller or a pre-existing controller.