Clone repository to: $PROJECT_DIR/terraform-provider-oktapam
where $PROJECT_DIR
is a directory within your local machine.
$ git clone git@github.com:okta/terraform-provider-oktapam $PROJECT_DIR/terraform-provider-oktapam
Go to the provider directory and build the provider
$ cd $PROJECT_DIR/terraform-provider-oktapam
$ make build
- You will need to create a service user
- Keep a copy of the new service user key and secret, you will be prompted with those after creating the service user
- Make sure the new service user is added to the appropriate PAM Groups and have the needed capabilities
- Set the following environment variables prior to running:
export OKTAPAM_KEY=<service user key>
export OKTAPAM_SECRET=<service user secret>
export OKTAPAM_TEAM=<team name>
If you want to test against a non-production server, you need to set the URL via:
export OKTAPAM_API_HOST=<root url for host here>
If the non-production server is not within the scaleft.com
or okta.com
domains, you will need to set the OKTAPAM_TRUSTED_DOMAIN_OVERRIDE
environment variable to the full domain being used, e.g.:
export OKTAPAM_API_HOST="https://my.testing.domain"
export OKTAPAM_TRUSTED_DOMAIN_OVERRIDE="my.testing.domain"
To compile the provider, run make build
. This will build the provider and put in the project directory
$ make build
To install the provider on your local machine, run make install
. This will build the provider and install it within the ~/.terraform.d/plugins/hashicorp.com/okta/oktapam/[VERSION]/[OS_ARCH]/terraform-provider-oktapam
directory.
$ make install
If you are using terraform 0.12.x, you will need to run make link_legacy
. This will create a symlink in ~/.terraform.d/plugins/
to the binary that is created by make install
. You will only need to run make link_legacy
once.
$ make link_legacy
To add a new resource or data source using the new Terraform Provider Framework:
-
Create a new file in the
oktapam
directory with the nameresource_<resource_name>.go
ordata_source_<data_source_name>.go
. -
Define a new struct that implements the
resource.Resource
orresource.DataSource
interface. reference: terraform provider framework resource -
Implement the required methods:
Metadata()
: Returns the resource type name.Schema()
: Defines the schema for the resource or data source.Create()
,Read()
,Update()
, andDelete()
for resources.Read()
for data sources.
-
Register the new resource or data source in the
Resources
/DataSources
method inprovider_pluginframework.go
. -
Add any necessary helper functions or API client methods in
oktapam/client/
. -
Create corresponding test files (
resource_<resource_name>_test.go
ordata_source_<data_source_name>_test.go
) and implement acceptance tests. -
Create documentation in
docs/resources/<resource_name>.md
ordocs/data-sources/<data_source_name>.md
. Docs should be generated by terraform-plugin-docs by running the following command:
make generate
-
Run
go fmt ./...
to format your code if needed. -
Run
make test
to ensure all tests pass or you can run specific tests by setting theTESTARGS
environment variable. Check out below section for more details on running tests.
Remember to follow the existing patterns and coding standards in the project when adding new resources or data sources. take a look at existing resources for examples.(resource_server_checkout_settings.go)
While developing provider if you want to try a test configuration against development build of a provider then dev_overrides setting comes handy.
Terraform init command creates .terraform.lock.hcl file to store the version and checksums for the required providers. Normally, Terraform verifies version and checksums to ensure operations are made with the intended version of a provider. These version and checksum rules are inconvenient while developing a provider, because every time you build a new binary checksum is going to be different and require developer to delete the exiting .terraform.lock.hcl file and re-initialize it via init command.
To avoid all this hassle, set the dev_overrides in terraform config file. By default, terraform look for .terraformrc file under ${HOME} directory. If you want to change it then set TF_CLI_CONFIG_FILE env variable.
export TF_CLI_CONFIG_FILE=/home/developer/tmp/dev.tfrc
Terraform config file content:
provider_installation {
dev_overrides {
"okta.com/pam/oktapam" = "<path to terraform-provider-oktapam locally built binary>"
}
# For all other providers, install them directly from their origin provider
# registries as normal. If you omit this, Terraform will _only_ use
# the dev_overrides block, and so no other providers will be available.
direct {}
}
After performing above steps, there is no need to run terraform init command. You can directly perform other operations like terraform plan/apply etc.
Terraform Documentation for more details.
Note: If the test configuration file has references to multiple providers and for some of them you don't want development overrides then this may not be a preferred approach. Please refer githhub open issue.
In order to test the provider, you can simply run make test
.
$ make test
We have two sets of acceptance tests, one for an Advanced Server Access team, and one for an Okta Privileged Access team. There are some tests that are shared between the two suites.
Note: Acceptance tests create real resources, and often cost money to run. If you wish to test against a dev/test server, ensure that you have the OKTAPAM_API_HOST
variable set.
Some tests rely on a server already being enrolled for your team. The ID of this server should be assigned to the TF_ACC_VALID_SERVER_ID
environment variable.
export TF_ACC_VALID_SERVER_ID=<server id>
To run the full test suite of Acceptance tests for ASA, run make testacc
.:
$ make testacc
To run the full test suite of Acceptance tests for Okta PA, run make testaccpam
.:
$ make testaccpam
If you want to run specific acceptance tests then set TESTARGS variable. TestCaseFunctionName(t *testing.T) can be a regular expression too.
$ TESTARGS='-run TestcaseFunctionName' make testacc
Note that you'll need to sub testacc
for testaccpam
if the tests is an Okta PA test.
- Bump version in
Makefile
. - Add last version to
tag-checks.yml
. - Merge and make tag corresponding to the new version.
- Make release corresponding to new tag.
- In the
oktapam_project
resource the public key algorithm for certificate signing and validation can be set. By default, projects use thessh-ed25519
algorithm, but admins can configure the project to use thessh-rsa
to support legacy servers.ssh-rsa
has been deprecated by OpenSSH and should not be used, if possible.