Protected Systems are applications, services, or infrastructure that you want to protect with SGNL. In this guide, we’ll describe how to achieve fine-grained access control inside of AWS with Okta and SGNL, enabling the right amount of access to infrastructure and data inside of AWS. If you’d like to learn more about whether securing AWS with Okta and SGNL is right for your enterprise, visit our Securing AWS Blog or watch the video below to learn more.
With this integration, AWS and Okta need not know about the policies, systems of record, or any of the data in SGNL - it simply needs to pass to SGNL:
Authentication ensures that only authorized systems can make requests into SGNL, as well as verifying the identity of an integration in order to effectively evaluate Policies - to access Authentication settings, open your AWS protected system and select the Authentication tab
Click Generate Token
Give your token a descriptive name so that you know how it’s being used in the future and click to Generate Token
On the next screen, copy the token - this will be used by Okta to make access requests to SGNL using the SGNL Access Service API
Note: The value of this token is not available again after this screen, so ensure you securely store it for steps later in this guide
Integrating SGNL with Okta, for the purposes of securing AWS or any Application, relies on Okta Inline Hooks. Okta Inline Hooks enable Okta to make an outbound request that can be routed to SGNL, in order to determine:
a) whether a principal has access to a specific AWS environment b) what assets within an AWS environment a user should be able to access during a given session c) what roles to allocate to the user for the session, based on business context
A simple example of this in action is using Okta Hooks to ask whether a user can access a specific customer’s data in AWS for a given session. In this scenario, SGNL Customers have found that PrincipalTags offer the greatest level of flexibility and dyamism, when combined with existing AWS roles, to dynamically specify an individual principal’s (user, service, robot, etc) permissions for a given session.
AWS provides the flexibility to enable Principal Tags to be used directly in conjunction with other policies that might already exist in AWS, and enables interleaving the tag directly into a resource name.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": "arn:aws:s3:::sensitive-prod-${aws:PrincipalTag/customerId}*"
},
...
]
}
To get the appropriate set of access for a given session (and consequently the necessary tag), an inline hook is routed to SGNL at authentication time. The hook specifies the Customer ID for which the user is requesting access.
SGNL’s Access Service responds with a determination whether the acess to a specific customer is allowed for a given session:
{
"decisions": [
{
"action": "access",
"assetId": "{{customerId}}",
"decision": "Allow"
}
],
"evaluationDuration": 8,
"issuedAt": "2023-06-22T23:49:32.087875656Z",
"principalId": "alice.wu@sgnl.ai"
}
If Access is Allowed, the Customer’s ID is packaged into the Okta SAML Assertion as a PrincipalTag and then the user is redirected to AWS to be signed in. At policy evaluation time, AWS inspects the Principal Tag and appropriate policy, determining whether the principal should be allowed to access a given resource.
At this point, it’s likely that all decisions will either be Allow or Deny, based on the Default Decision you’ve selected for the AWS Integration - if that’s the case, you’re ready to start assigning policies.
Once the AWS integration is created, you can start assigning versions of Policies - to get started, select Policies from the tabs in your newly created integration
Select ‘Assign Policies’
Select:
Click Next once you have the Policies and Versions configured as is appropriate
Select the Enforcement mode for the Policies you chose in the previous step
Simulated: Policy Versions that are being simulated will only log their access decision in the SGNL logs and will not impact the access decision that SGNL hands back to an integration. Simulated policies are useful for performing what-if analysis of new policy versions as well as debugging policy changes.
Note: It’s considered best practice to start with policies in Simulated mode, to verify that policies have been created an applied as expected
Enforced: Policy Versions that are being enforced will impact the access decisions that SGNL hands back to an integration. Enforced Policies will determine access for an integration
Select your desired Enforcement mode and select Assign
Versions of Policies will now be Assigned to your integration
