anchore-engine icon indicating copy to clipboard operation
anchore-engine copied to clipboard

Feature request: Anchore policies as kubernetes custom resources

Open Atharex opened this issue 5 years ago • 3 comments

Managing policies over the API already works nicely, but it is still some manual steps necessary to maintain them and activate the desired ones

Was wondering, if it would be feasible to supplement this with an operator-style feature to Anchore, by making it possible to declare Policy Bundles as CRs? Those could encapsulate the policies, as well as make it easier to maintain and activate them in a GitOps style.

Atharex avatar Jan 30 '21 11:01 Atharex

Hi @Atharex this is an interesting idea and something I've thought about before. How do you envision the workflow and activations working? I assume you're thinking about a way to manage multiple policies and multiple accounts. I can think of a few ways to do this, what are your thoughts?

zhill avatar Jan 31 '21 21:01 zhill

Did not put that much thought into it initially to be honest :)

I guess multiple CRDs would be needed to handle all of the workflows. Probably an account CR is the top level one, which has to be referenced by user CRs & policy CRs. The references would be a failsafe check, if the account already exists and would fail to apply if it does not. For activations I guess the policy CR would have a field active: true and the last policy that was applied with this field would be the active one (the others would have to be switched to active: false in the background). If a policy would be applied with active: false then the currently active one would be left active. If multiple Policies with active: true would try to be applied in the same kubectl apply command, it should error out and not apply anything

For the policies I'm not sure if they are applied to accounts or users, but assuming it is to accounts, then perhaps the policy CR could also have a list of accounts instead of only a single account, so it could be applied to multiple more easily. In that case the failsafe would need to make sure applying a policy CR would fail if any of the given accounts do not exist already. Not sure if this should also apply to disabled accounts...

Guess a high level sketch could look something like this:

apiVersion: anchore.io/v1alpha1
kind: Account
metadata:
  name: admin-account
  namespace: anchore
spec:
  enabled: true
  type: admin
  account:
    name: admin-account
    email: [email protected]

---

apiVersion: anchore.io/v1alpha1
kind: User
metadata:
  name: admin-user
  namespace: anchore
spec:
  type: native
  accountName: admin-account   ## reference to the account
  user:
    credentialsSecret: kubernetes-secret-with-un-pw    ## secret would need to be prepared beforehand

---

apiVersion: anchore.io/v1alpha1
kind: PolicyBundle
metadata:
  name: custom-policy
  namespace: anchore
spec:
  active: true
  accounts:   ## a list of referenced accounts
  - admin-account
  policyBundle:
  ...
  <YAML or JSON defined policy bundle>
  ...

Atharex avatar Feb 03 '21 16:02 Atharex

Hi @zhill any developments on this? Would still love to see anchore management with a GitOps approach :)

Atharex avatar Jun 16 '21 09:06 Atharex