Conjur upgrade instructions for FIPS compliance

[hilagross]

In this card, we define upgrade instructions that will be required once #1527 is merged.

See #1528 for more info on standard Conjur upgrade instructions.

Following steps were performed to upgrade from OSS v.{x} to OSS v.{x+1}:

1. Edit docker-compose.yml conjur service image tag to {x+1}
2. Delete current conjur container: docker rm -f conjur
3. Rerun docker-compose: docker-compose up -d
4. View docker containers and verify all are healthy, up and running: 'docker ps -a`

• side note, it is possible you will need to reassign CONJUR_DATA_KEY system variable. Same key as before. export CONJUR_DATA_KEY="$(< data_key)

These steps should be done after OpenSSL change Steps 5-12 can be replaced by bundle exec rake slosilo:migrate FINGERPRINT UPDATE WORKAROUND STEPS:

5. Use any host/user (i.e: admin/dave/botapp...) and same API key to authenticate see docs: https://docs.conjur.org/Latest/en/Content/Developer/Conjur_API_Authenticate.htm?tocpath=Developer%7CREST%C2%A0APIs%7C_____2

6. Once obtained "short-lived access token" from response, transfer it to dot seperated token in following format: protected.payload.signature e.g:

   "protected": "eyJhbGciOiJjb25qdXIub3JnL3Nsb3NpbG8vdjIiLCJraWQiOiI0NGIwMjBmNjY0MDBmNzFhZDQ3Y2I0N2IzYTFiNmU5MSJ9",
   "payload": "eyJzdWIiOiJhbGljZSIsImlhdCI6MTUwNTgzMDY1MX0=",
   "signature": "iRLTwNomb_b6TS4e539IIC-isPsc0kIn-F_ajlvnGdrN6brEEHnVha2vm0oDwOjpnmpFrMYLzn8aPo4_7DP3edssfQbpMG6OZI2Ea9DRfkhQGtSQ2fQvhDos_f16EX_jWQkYlsY6T_RurAxf_7VC4hEhjZA8nLkXOohA1DheyoJiT2-7vdpLmf42G7r1gPWHd_JuFkee28Ax2vCi35l4yQXkAHFaLkb3cAD2iwYuavv3qcFnYsT5WhLQqndPoNzgNa4dMvWRkVNUoVmvL30oE6lAlWPO4rFbPpmLwJRJFudDF8IVV9cVRKnV3z79_3RfEsHJ6YTHVX4Cv--cXmkT17QSFp87DK94DAOX3jKvJNo49DdqkzXqAPUIj3CD3IWI"
   }

   Will be transferd into:

   eyJhbGciOiJjb25qdXIub3JnL3Nsb3NpbG8vdjIiLCJraWQiOiI0NGIwMjBmNjY0MDBmNzFhZDQ3Y2I0N2IzYTFiNmU5MSJ9.eyJzdWIiOiJhbGljZSIsImlhdCI6MTUwNTgzMDY1MX0=.iRLTwNomb_b6TS4e539IIC-isPsc0kIn-F_ajlvnGdrN6brEEHnVha2vm0oDwOjpnmpFrMYLzn8aPo4_7DP3edssfQbpMG6OZI2Ea9DRfkhQGtSQ2fQvhDos_f16EX_jWQkYlsY6T_RurAxf_7VC4hEhjZA8nLkXOohA1DheyoJiT2-7vdpLmf42G7r1gPWHd_JuFkee28Ax2vCi35l4yQXkAHFaLkb3cAD2iwYuavv3qcFnYsT5WhLQqndPoNzgNa4dMvWRkVNUoVmvL30oE6lAlWPO4rFbPpmLwJRJFudDF8IVV9cVRKnV3z79_3RfEsHJ6YTHVX4Cv--cXmkT17QSFp87DK94DAOX3jKvJNo49DdqkzXqAPUIj3CD3IWI

7. Browse to https://jwt.io/, insert dot seperated token into enocde textbox, extract kid from decode header section - this will be your new figerprint.

8. Enter PG container from your terminal: docker exec -it postgres bash

9. Switch user to postgres su postgres

10. Use psql cli to login psql

11. Be familiar with content of slosilo_keystore table select * from slosilo_keystore; notice you have 3 columns: id, key, fingerprint, extract id record will be similar to: authn:myConjurAccount

12. Edit account recored with new fingerprint update slosilo_keystore set fingerprint = '{VALUE FROM STEP 7}' where id = '{VALUE FORM STEP 11}';

13. To verify, run step 5 and use short-lived-token to do any action, fetch secrect load policy etc.

[izgeri]

@hilagross have you verified that steps (1) - (4) are all that's required if the conjur version bump includes database migrations? it seems like a step is missing there

I'd like to make this card "Conjur upgrade instructions for FIPS compliance" and refer to #1527 to be clear that this card holds the custom upgrade instructions for an upcoming release

I'd like to make the original card I filed #1528 be where we start tracking the standard, uncomplicated upgrade instructions for a typical Conjur release. and it would include steps (1) - (4) (it looks like) as well as any special instructions if the release includes a DB migration

Does that make sense to you too? (cc @alexkalish)

[hilagross]

Hi @izgeri , Creating a new issue was @alexkalish request. The steps was copied from #1528 and was verified by @uCatu.

As there is no upgrade process some step may no be done as expected and that what we should try to solve here. Steps 1-4 are the basic the team done Steps 5-12 are done due to the change, but can be replace (after testing) with one line bundle exec rake slosilo:migrate

[alexkalish]

@hilagross: Thanks for filing this issue. Could you please update the description with the following:

1. The rake task you mention above.
2. Some description about what this step is doing and why it's needed? As we discussed with @InbalZilberman, I think it's important to give the user some understanding about why this special step is needed to go from Conjur 1.x to 1.x+1.
3. Where these changes are going to be made? I think we had discussed minimally putting them into README.md, but an UPGRADING.md could be a good option. Thoughts, @izgeri? Also, will someone on Roee's team be taking this issue?

@izgeri: Yup, LGTM.

[izgeri]

I think the standard typical upgrade instructions (eg the output of #1528) should be added to README.md in this project in a new Upgrade Instructions section.

For the custom upgrade instructions for a specific release - where they should live is a really good question. The maintainer who creates the tag for the Conjur release that includes the changes from #1527 will need to be aware that special upgrade instructions are required, and I'm not sure about the best way to flag that (except perhaps to cc @jvanderhoof and @sjacobs146 here).

Once the new tag containing the changes from #1527 is created, the GitHub release should include an "Upgrade Instructions" section in addition to the "Change log" section that we currently post. I think it would be great if this card could have the final draft of those instructions, so that at release time adding them to the GitHub release notes (which will propagate to the suite release notes) will be a matter of copy/paste.

Please let me know if you have any suggestions to improve the process I've proposed above. I don't love that it has some manual steps, but it is our first time considering this carefully :)

[hilagross]

Hi @alexkalish , As I wrote before: Steps 5-12 can be replaced by bundle exec rake slosilo:migrate however, we didn't tested it.

As we talked with @InbalZilberman and in the meeting summary, I provided the steps that was done, I can provide the reason for why this needs to be done, but where and how should be done by you. As mentioned before, Roee's team still working on FIPS feature with a strict deadline so we are unable to take this task any further.

[izgeri]

@hilagross is there an issue for implementing the bundle exec rake slosilo:migrate rake task? can we refer to that issue here, please?

[hilagross]

Hi @alexkalish, I created a new UPGRADING.md and a PR: https://github.com/cyberark/conjur/pull/1607 As discussed with Inbal I added to it only the rake task step, but as I said it wasn't tested as a rake task only manually as one step at a time (step 5-12 above). As discussed with @InbalZilberman currently Roee's team don't have capacity to test the rake task, please make sure to test it.

[h-artzi]

Upgrade Issue: When upgrading from a pre-FIPS compliant version to a FIPS-compliant version, the fingerprints in slosilo were never updated and led to authentication issues.

Solution:

• A rake task was added in the gem slosilo which recalculates the fingerprints
• A new database migration step updates the fingerprints by calling the rake task.

Positive:

• No additional step other than running db:migrate is needed to make appropriate changes to the DB
• It clearly portrays what happens to the DB during an upgrade

Downside:

• We currently do not support a downgrade option. If a user runs into any issues, we hope to be able to address their concerns.

[izgeri]

@h-artzi I'm going to reopen this until we get the UPGRADING.md onto the master branch as well

[izgeri]

This was resolved in #1607. Please note we do not yet have a post-FIPS Conjur OSS release that has working, simple upgrade instructions; you can watch our releases page for when that version will become available.