AWS Template Okta Authentication

Hi -
I’m looking to see if there is a way to accomplish this. We us OKTA to authenticate with AWS. My Octopus Server is currently On-Prem and I was looking to take advantage of using the cloudformation template.

I understand that I can setup things up this way https://octopus.com/docs/deployment-process/variables/aws-account-variables using an access key and secret key.

But in order to get this to work with OKTA I need to be able to pass Session token as well. Is that possible?

thanks

Hi,

Thanks for getting in touch. Just to clarify what you’re after, you want to create a user in Okta and have Octopus log in to AWS as that user?

If so, this isn’t a scenario we’ve had customers ask for previously so I’m just trying to come up to speed on it. Some quick reading on the AWS and Okta integration seems to indicate it requires an AWS IAM to use and then it manages IAM things for users who are doing interactive logins. Octopus AWS Accounts are designed to use IAM directly (i.e. it doesn’t connect as any end user who’d be in Okta), so is Okta going to just be adding additional complexity to the setup for automation?

I may be misunderstanding the scenario, so if I am please let me know.

Regards
Shannon

Yes, that is the basic scenario. So the high level plan is put in a Pid into Okta and use that Pids credentials to validate in OKTA into AWS.

If I were to use the CLI internally using my Okta credentials we do the following:
aws --<PROFILE NAME> configure set credential_process "awsprocesscreds-saml -e <!PATH IN OKTA TO AWS> -u <ID LOOKING TO USE> -p okta -a arn:aws:iam::<ROLE INFORMATION>"

This will create an AWS profile. Then when calling anything in the CLI you can use the --profile and specify

If you session is dead, it will ask you for your password otherwise it authenticates.

Let me know if this makes sense or you need more information.

I may be wrong, but I don’t believe this approach will work for automation from Octopus. When Octopus connects to AWS it does so in a non-interactive session, so anything that could prompt for passwords would block the flow and make the deployment “hang” waiting for input.

The way Octopus interacts with AWS is more like how Okta itself interacts with AWS. I.e. it is a service that performs operations on the user’s behalf. Changing this isn’t something we have on our radar at this stage. A compelling enough case can change priorities though.

Regards
Shannon