Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Okta Provider migration: Okta ASA to Okta PAM #104

Open
Akp-repo opened this issue May 22, 2023 · 9 comments
Open

Okta Provider migration: Okta ASA to Okta PAM #104

Akp-repo opened this issue May 22, 2023 · 9 comments

Comments

@Akp-repo
Copy link

Hi Team,
we are planning to migrate terraform Okta provider from Okta ASA to Okta PAM, is there any best way to migration all the projects in bulk.
we have around 200 project and all need to migrate.
Please suggest.

@sudgopal
Copy link

Hi team - when we are trying to import project created using ASA provider onto PAM provider using below command

terraform import oktapam_project.pam_tfprovider_poc fi-aws-poc-oktaasa-tfprovider

we are facing below error message

Error: The provider returned a resource missing an identifier during ImportResourceState. This is generally a bug in the resource
implementation for import. Resource import code should not call d.SetId("") or create an empty ResourceData. If the resource is missing, instead return an error. Please report this to the provider developers

Can you please help troubleshooting the issue? Thanks.

@waltergoulet-okta
Copy link
Contributor

@sudgopal Can you please enable debug logging and provide debug log entries from running this command? I can't tell from your input exactly which resource is missing an identifier and hopefully debug logs will point us in the right direction.

Thanks!

@sudgopal
Copy link

sudgopal commented Jul 31, 2023

Hi @waltergoulet-okta - sorry for the false alarm. We were able to complete the following import operation

terraform import oktapam_project.pam_tfprovider_poc fi-aws-poc-oktaasa-tfprovider

However, should we import enrollment token as well as Group using the same command?

Also, once "terraform import" is done, should we perform "terraform rm" of enrollment token, group and project (created using ASA provider) in that same order?

Please let us know.

Thanks.

@waltergoulet-okta
Copy link
Contributor

Hi @sudgopal It would help if you could explain your overall goal so we can advise as to what your approach should be. In general, based on what you are specifically trying to do will determine which resources you should import. Can you perhaps describe at a high level what you are doing?

@sudgopal
Copy link

Hi @waltergoulet-okta -

We have close to 150+ ASA projects (and associated groups, enrollment tokens) that were created using ASA terraform provider.

We are in the process of figuring out best possible way to migrate from ASA provider to PAM provider without causing disruptions to existing ASA infrastructure. We thought of using terraform import and rm to achieve this

Can you please help us to figure out the exact steps to be done in the migration?

Thanks,

@sudgopal
Copy link

sudgopal commented Aug 3, 2023

Hi @waltergoulet-okta - Bumping this request up in the queue.

Can you please help us to figure out the exact steps to be done in the migration?

Thanks,

@waltergoulet-okta
Copy link
Contributor

Hi @sudgopal, thanks for outlining your use case. At a high level, I think your goal should be to treat what is currently in your ASA team as the authoritative source of truth and to generate new resources using the OktaPAM Terraform provider that reflect your current ASA configuration. So my suggestion would be to use the OktaPAM Terraform provider to import projects, ProjectGroups and Enrollment tokens so you have a new state that is generated purely by the new provider (assuming these are the resources that you currently manage with the ASA provider.) I would suggest starting by making a new Project with an enrollment token as well as a ProjectGroup bound to it for testing with the current ASA provider that mirrors configuration you have for other projects you will be importing. Then I would suggest importing only this Project with 'terraform import' using the new OktaPAM terraform provider so that you have state reflecting the Project created with the ASA provider available locally and imported into resources known to the new provider. Finally, I would suggest modifying some aspect of the new configuration you created with the new provider and apply it back to verify that the changes made correctly applied back to the test project.

I haven't personally tested this flow out, but the general approach should work. Also, you might try experimenting with the terraform generate configuration experimental feature to see if that can help simplify recreating new configuration compatible with the new provider.

@sudgopal
Copy link

sudgopal commented Aug 3, 2023

Hi @waltergoulet-okta - Thanks for your response; For this proof of concept, I am thinking of below workflow. Can you please help with queries in step 3 and step 5? Thanks.

Step 1) Create a new Project with an enrollment token as well as a ProjectGroup bound to it - using current ASA provider (this setup mirrors configuration of other actual ASA projects)

Step 2) Collect the ASA project id from terraform statefile

Step 3) Perform "terraform import oktapam_project.pam_tfprovider_poc "
Should we need to import ASA group and server enrollment?

Step 4) Validate

Step 5) Perform cleanup of ASA resources using "terraform rm"
Should we need to cleanup ASA group and server enrollment?

@waltergoulet-okta
Copy link
Contributor

I would think for step 3 you would want to import the server enrollment token as well, since your goal is to basically transition your existing ASA configuration into new state and config files understood by the OktaPAM TF provider. Same for the ProjectGroup assignments as well. As for step 5, yes I suppose that is a good idea if you are thinking that you will one at a time migrate projects and related config from being under management of the oktaasa provider to the OktaPAM provider (this way, existing config/state remains in oktaasa provider so you can still manage projects you haven't migrated yet).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants