Modifying annotation values

[Pieter (Pieter Voet)]

Hi,

I want to modify the annotation values from a variable entry in a policy.

A while ago, still on Slack, we discussed this, and the way to do this is to ‘replace’ a policy.
Using REST, this will be a PUT method on the policy identifier, together with the new policy data.

So, from Python using REST calls to Conjur, I’m able to retrieve the policy that contains the variable
entry where I want to change existing annotation values, but the current policy data is not there.
Over time, there were some modifications to the policy ( e.g. grants ), and I can see those
modifications in the ‘policy_versions’ array. But the ‘policy_version’ only contain delta’s, and there’s
no current definition return by HTTP GET
Recreating the policy by walking all these ‘policy_versions’ would really be a nasty job to do.

‘replacing’ the policy for the modified annotations requires the complete policy definition, because only explicit defined resources will get created. Meaning I’ll need to have a complete definition of the policy in it’s current state, including possible other variables, permits, hosts, bodies etc…

My question is : how can I get the complete policy definition ?

Having said that, I’d really prefer a ‘policy update’ (HTTP PATCH) to just change the annotation values… and leaving all the other policy parts as they are… But apparently that is not supported.
Also, ‘append to policy’ only appends, and does not modifying already existent annotation values.
But hey, if ‘replace policy’ is the way to go, then I’ll go for that.

Hopefully my problem description is clear enough. If not, let me know, and I’ll elaborate some more.

Thanks for any help in advance.

[nathan.whipple (Nathan)]

Hi Pieter,

We could certainly request a feature enhancement here, but currently replace is the only option. Is there a reason one would reasonably be expected to NOT have a complete definition of the current policy? My recommendations to customers center around managing policy through an SCM repo with code check-in and review workflows and always loading policy with the replace option. The SCM repo provides versioning, roll-back capability, and review controls while ensuring that applied policy is explicitly defined. I’m curious what scenario you’re working with that has requirements this approach can’t satisfy.

[Pieter (Pieter Voet)]

Hi Nathan,

I’m currently writing an Ansible lookup plugin for Conjur. I know there is one aronud, but that implementation is too basic.
So, I’m interfacing to a live Conjur instance, meaning that policy entries could have changed (programmatically) since the initial load. An initial load probably is done through a policy file ( which can be stored in an SCM repo ) , but all other policy mutations are done afterwards using the REST interface. So, there’s no policy file representing the current policy state.
Even if policy mutations were done using files ( appends ), then the initial policy file does not
represent the current state anymore.

[nathan.whipple (Nathan)]

Hi Pieter,

Sadly I have to admit that I’m struggling to follow here. My use of the term “lookup plugin” is to fetch secrets that already exist in Conjur for use in playbooks and so on. I wouldn’t use that term to describe creating policy that I load into Conjur. It sounds like you are doing something a bit more extensive here though. Would it be possible for us to take this up a few layers and outline the use case again in a more general sense to better frame this specific problem?

-Nate

[Pieter (Pieter Voet)]

Hi Nathan,

OK, then forget about the lookup plugin, but just discuss the fact that the REST API supports modification…
As described by ‘https://docs.conjur.org/Latest/en/Content/API/#policies’, I can use Python and it’s
‘urllib’ package for example, to modify the Conjur content right ?
So, there can be any mutation on any given time that will render the initial load policy yaml outdated. Besides that, even the initial load of a policy can be done programmatically, so relying on a file that once represented an initial state for policy recreation, is probably not a solid approach.

Will this elaborate a bit more on my need to query the current policy definition ?

Thanks for your time !

Pieter

[Pieter (Pieter Voet)]

Hi,

I ran into another issue with this.
For project-progress sake, I wrote some code that reassembles the policy definition using all entries in the ‘policy_versions’. The code then modifies the annotation values of some variable, and replaces the policy. This appeared to work…

However … I now run into a situation where the ‘policy_versions’ array is empty, although the policy has variables defined ! So, there’s no way that I can recreate the policy !

Consider the following steps :

docker-compose run --no-deps --rm conjur data-key generate > creds/data_key
export CONJUR_DATA_KEY=$(< creds/data_key)
docker-compose exec conjur conjurctl account delete BCIE
docker-compose exec conjur conjurctl account create BCIE > creds/admin_data
docker-compose exec -T client conjur auth login -u admin -p $(< creds/admin_data)

cat conf/policy/TC_base.yml :

- !group
  id: bcie_conjur_admin_grp
  owner: !user admin
  annotations:
    Title: bcie_conjur_admin_grp
    UserName: bcie_conjur_admin_grp
    URL:
    Notes:

- !user
  id: bcie_conjur_admin
  owner: !group bcie_conjur_admin_grp
  annotations:
    Title: bcie_conjur_admin
    UserName: bcie_conjur_admin
    URL:
    Notes:

- !grant
  role: !group bcie_conjur_admin_grp
  members:
    - !user bcie_conjur_admin

- !policy
  id: ont
  owner: !group bcie_conjur_admin_grp
  annotations:
    Title: ont
    UserName: ont 
    URL:
    Notes:

cat conf/policy/TC_base.yml | docker-compose exec -T client conjur policy load --replace root - > creds/TC_base.creds
docker-compose exec -T client conjur auth login -u bcie_conjur_admin -p $(< creds/TC_base.creds)

cat  conf/policy/TC_ont.yml :

- !group
  id: bcie_conjur_admin_ont_grp
  owner: !group /bcie_conjur_admin_grp 

- !policy
  id: ADS
  owner: !group bcie_conjur_admin_ont_grp
  annotations:
    description: Active Directory
  body:
    - &variables
      - !variable
        id: bpmadswrite
        kind: 
        annotations:
          Title: 
          UserName: 
          URL:
          Notes: 
        
      - !variable
        id: BPM_ONT
        kind: Bind user voor websphere runtime
        annotations:
          Title: BPM_ONT
          UserName: BPM_ONT
          URL:
          Notes: Bind user voor websphere runtime
        
      - !variable
        id: AAYTS26
        kind: 
        annotations:
          Title: 
          UserName: 
          URL:
          Notes: 

cat  conf/policy/TC_ont.yml | docker-compose exec -T client conjur policy load --replace ont - > creds/TC_ont.creds 

This basically reinitializes a Conjur database with minimal context. A ‘ont/ADS’ policy is defined, that contains three variables. However, displaying the ‘ont/ADS’ policy shows no ‘policy_versions’ data :

$ docker-compose exec client conjur show "BCIE:policy:ont/ADS"
{
  "created_at": "2019-11-15T15:00:17.906+00:00",
  "id": "BCIE:policy:ont/ADS",
  "owner": "BCIE:group:ont/bcie_conjur_admin_ont_grp",
  "policy": "BCIE:policy:ont",
  "permissions": [

  ],
  "annotations": [
    {
      "name": "description",
      "value": "Active Directory",
      "policy": "BCIE:policy:ont"
    }
  ],
  "policy_versions": [

  ]
}

I cannot use policy replace if I can’t get all variable definition data. If I just create yaml that defines new data for one particular variable and use ‘policy replace’, it will destroy the other variables.

Can somebody please help me out on this ? I just want to be able to modify variable annotation values.

Thanks in advance.
Pieter

[AndrewCopeland]

Hi Pieter,

Please refer to my comment here: Overwriting or deleting annotations on resources in Conjur

I do not know if there is a way to explicitly delete annotations but if you need to explicitly update an annotation you can use the PATCH method when uploading policy.

Thanks,
Andrew

[Pieter (Pieter Voet)]

Hi Andrew,

great ! That was exactly what I was looking for !

Although I’m happy that this’ll get me going again, it’s not very intuitive to
update a policy for a ‘variable’ entity. But hey, it works !

Thanks a lot for your help.

[jake]

@Pieter Thanks for the feedback! What do you think might be more intuitive? I know I’ve heard this a few times for policies