Forward Deployed Engineer 101: Identity and Access Management (RBAC, ABAC, SSO, MFA)

Identity and Access Management (RBAC, ABAC, SSO, MFA)

Field-Ready Study Guide: Identity and Access Management (RBAC, ABAC, SSO, MFA)

For Forward Deployed Engineers (FDEs) operating in high-stakes, constrained environments

What This Is

Identity and Access Management (IAM) is the backbone of security in chaotic, real-world deployments—whether you're standing up a classified ML pipeline for a DoD customer, debugging a broken SSO integration during a disaster response mission, or hotfixing an RBAC misconfiguration that’s blocking a critical data feed. As an FDE, you’ll spend 30-50% of your time dealing with IAM: debugging permissions, negotiating access controls with security teams, or working around air-gapped constraints. Example: You’re on-site at a hospital deploying a COVID-19 analytics tool, and the customer’s Active Directory (AD) team refuses to grant your service account the right permissions. You have 2 hours before the CIO’s demo—do you escalate, work around it, or rewrite the auth layer?

Key Terms & Concepts

• RBAC (Role-Based Access Control):
  Assigns permissions to roles (e.g., data-scientist, admin) rather than individual users. Used in Kubernetes (Role, ClusterRole), AWS IAM, and enterprise tools like Okta. Field note: Always start with the principle of least privilege—customers will ask for admin; push back and ask, “What exactly do you need to do?”

• ABAC (Attribute-Based Access Control):
  Grants access based on attributes (e.g., department=finance, clearance=top-secret, time=9am-5pm). More flexible than RBAC but harder to audit. Tools: AWS IAM (with Condition blocks), Open Policy Agent (OPA). Example: Only allow S3 bucket access if the user’s clearance tag matches the bucket’s classification tag.

• SSO (Single Sign-On):
  Lets users log in once (e.g., via Okta, Azure AD, or Google Workspace) and access multiple apps. Field trap: SSO breaks in air-gapped environments—always have a fallback (e.g., local LDAP or static credentials).

• MFA (Multi-Factor Authentication):
  Requires two+ factors (e.g., password + TOTP, YubiKey, or biometrics). Tools: Duo, Google Authenticator, AWS MFA. Field note: MFA is non-negotiable in regulated environments (e.g., FedRAMP, HIPAA). If the customer resists, escalate to their security team—you are not the one to waive this.

• Service Accounts:
  Non-human identities for apps/services (e.g., Kubernetes ServiceAccount, AWS IAM roles). Field tip: Never hardcode credentials—use short-lived tokens (e.g., AWS STS, Kubernetes TokenRequest).

• LDAP / Active Directory (AD):
  Directory services for user/group management. Tools: ldapsearch (CLI), Python’s ldap3 library. Example command: bash ldapsearch -x -H ldap://dc.example.com -b "dc=example,dc=com" -D "cn=admin,dc=example,dc=com" -W "(uid=jdoe)"

• OAuth 2.0 / OpenID Connect (OIDC):
  Standards for delegated auth (OAuth) and identity (OIDC). Tools: curl for testing, python-oauth2 for scripting. Example: Use OIDC to let users log in via Google/GitHub in a web app.

• SAML 2.0:
  XML-based SSO standard (common in enterprise). Tools: saml2aws (CLI), Python’s python3-saml. Field note: SAML is a pain to debug—use saml-tracer (browser extension) to inspect assertions.

• Just-In-Time (JIT) Provisioning:
  Creates user accounts on first login (e.g., via Okta or Azure AD). Field use: Critical for onboarding new users in dynamic environments (e.g., disaster response).

• Privileged Access Management (PAM):
  Controls access to admin accounts (e.g., CyberArk, HashiCorp Vault). Field tip: If the customer uses PAM, you’ll need to request temporary credentials—plan for this in your deployment timeline.

• Zero Trust:
  “Never trust, always verify.” Assumes breach and verifies every request. Tools: BeyondCorp (Google), AWS IAM, Kubernetes Network Policies. Field note: Zero Trust is the default in defense/intel—expect to justify every network call.

• Federated Identity:
  Links identities across systems (e.g., AWS IAM + Okta, or DoD’s Common Access Card (CAC) + AD). Field trap: Federation breaks if the customer’s IdP (e.g., Okta) is unreachable—always test failover.

Step-by-Step / Field Process

1. Discovery: Map the Customer’s IAM Landscape

• Action: Ask for:
• Their IdP (Okta, Azure AD, ADFS, etc.).
• Existing roles/groups (e.g., “What’s your data-analyst role allowed to do?”).
• MFA requirements (e.g., “Do you use hardware tokens or TOTP?”).
• Any air-gapped constraints (e.g., “Can we reach your IdP from our deployment network?”).
• Tool: Use curl or ldapsearch to test connectivity: bash curl -v https://idp.customer.com/.well-known/openid-configuration # Test OIDC ldapsearch -x -H ldap://ad.customer.com -b "dc=customer,dc=com" # Test LDAP
• Field tip: If the customer can’t answer, ask for their security policy document (e.g., “Can you share your IAM SOP?”).

2. Design: Choose the Right Model (RBAC vs. ABAC)

• RBAC: Use when permissions are static and role-based (e.g., “All analysts can read S3 bucket X”).
• Example (Kubernetes):
  ```yaml
  apiVersion: rbac.authorization.k8s.io/v1
  kind: Role
  metadata:
  name: data-analyst
  rules:
  • apiGroups: [""] resources: ["pods"] verbs: ["get", "list"] ```
• ABAC: Use when permissions depend on attributes (e.g., “Only users with clearance=secret can access this dataset”).
• Example (AWS IAM):
  json
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::classified-data/*",
"Condition": {"StringEquals": {"aws:PrincipalTag/clearance": "secret"}}
}
• Field tip: Start with RBAC—it’s easier to audit. Only use ABAC if the customer demands dynamic permissions.

3. Implement: Deploy with Least Privilege

• Action:
• Create a minimal IAM policy (e.g., AWS IAM, Kubernetes Role).
• Test with a non-admin user (e.g., aws sts assume-role or kubectl auth can-i).
• Iterate: Add permissions only when the user hits a “permission denied” error.
• Example (AWS CLI): bash aws sts assume-role --role-arn arn:aws:iam::123456789012:role/data-analyst --role-session-name test export AWS_ACCESS_KEY_ID=... AWS_SECRET_ACCESS_KEY=... AWS_SESSION_TOKEN=...
aws s3 ls s3://classified-data/ # Should fail if permissions are correct
• Field tip: Use aws iam simulate-principal-policy to test permissions before deploying.

4. Integrate SSO/MFA

• Action:
• Configure the app to use the customer’s IdP (e.g., Okta, Azure AD).
• Test with a non-admin user (e.g., “Can jdoe log in with MFA?”).
• Set up a fallback (e.g., local LDAP or static credentials for air-gapped environments).
• Example (OIDC with curl): bash # Get OIDC config curl https://idp.customer.com/.well-known/openid-configuration | jq '.authorization_endpoint' # Test login flow (replace CLIENT_ID/SECRET) curl -X POST "https://idp.customer.com/token" \
-d "grant_type=password&username=jdoe&password=...&client_id=...&client_secret=..."
• Field tip: If SSO fails, check:
• Is the IdP reachable from the deployment network?
• Are the client_id/secret correct?
• Is MFA enforced? (If so, you’ll need a test user with MFA disabled.)

5. Debug: Reproduce and Fix Permission Issues

• Action:
• Reproduce the error (e.g., “User jdoe can’t access the S3 bucket”).
• Check logs (e.g., AWS CloudTrail, Kubernetes audit logs).
• Use kubectl auth can-i or aws iam simulate-principal-policy to test.
• Fix the policy and redeploy.
• Example (Kubernetes): bash kubectl auth can-i get pods --as=jdoe -n default # Should return "yes" or "no" kubectl get rolebindings -n default # Check if jdoe is bound to the right role
• Field tip: If the customer says, “It worked yesterday,” check:
• Did their IdP rotate credentials?
• Did a security team revoke permissions?
• Is the app caching old tokens?

6. Document and Handoff

• Action:
• Write a runbook for the customer (e.g., “How to add a new user to the data-analyst role”).
• Document:
  • The IAM model (RBAC/ABAC).
  • How to request permissions (e.g., “Email [email protected] with the user’s email and role”).
  • Fallback procedures (e.g., “If SSO fails, use local LDAP credentials”).
• Schedule a handoff meeting with the customer’s security team.
• Example runbook snippet: ```markdown ## Adding a New Data Analyst
• Go to Okta Admin Console → Directory → Groups.
• Add the user to the data-analyst group.
• The user will gain access within 5 minutes.
  ```

Common Mistakes

FDE Interview / War Story Insights

1. The “We Need This Now” Escalation

• Scenario: You’re on-site deploying a data pipeline. The customer’s CIO demands a new role with admin permissions immediately for a VIP user. The security team says no.
• How to respond:
• Acknowledge: “I understand this is urgent.”
• Clarify: “What exactly does the VIP user need to do? Can we scope the permissions to just that?”
• Escalate: “Let me loop in your security team to find a solution that meets both needs.”
• Why: Never bypass security—you’ll be the one blamed if something breaks.

2. The “It Works in Dev” Trap

• Scenario: Your app works in your lab but fails in the customer’s environment. The error is 403 Forbidden.
• Debug steps:
• Check if the customer’s IdP is reachable (curl or ldapsearch).
• Verify the user’s role/attributes (e.g., aws iam get-user or kubectl get rolebindings).
• Test with a non-admin user (e.g., aws sts assume-role).
• Field tip: Always test in the exact customer environment—what works in your lab will break behind their firewall.

3. The Air-Gapped SSO Nightmare

• Scenario: You’re deploying to a classified network with no internet access. The app requires SSO (e.g., Okta), but the IdP is unreachable.
• Solutions:
• Fallback to local auth: Use LDAP or static credentials (document this in the runbook).
• Offline IdP: Deploy a local IdP (e.g., Keycloak) and sync users manually.
• CAC/PKI: If the customer uses smart cards (e.g., DoD CAC), integrate with their PKI.

Quick Check Questions

1. You’re deploying a Kubernetes app to a customer’s cluster. The security team says, “No ClusterRole for you—only Role.” What’s your first step?

• Answer: Ask, “What namespaces does my app need to access?” Then create a Role scoped to those namespaces.
• Why: ClusterRole is global (security risk); Role is namespace-scoped (safer).

2. A customer’s SSO integration fails with invalid_client. What’s the most likely cause?

• Answer: The client_id or client_secret is incorrect, or the redirect URI doesn’t match the app’s configuration.
• Why: SSO is picky about exact matches—check the IdP’s logs for details.

3. You’re debugging an AWS Lambda that can’t access an S3 bucket. The error is AccessDenied. What’s your first debug command?

• Answer:
  bash aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::123456789012:role/lambda-role --action-names s3:GetObject --resource-arns arn:aws:s3:::bucket-name/*
• Why: This simulates the Lambda’s permissions without deploying code.

Last-Minute Cram Sheet

1. RBAC = Roles + RoleBindings (K8s) or IAM Roles (AWS).
2. ABAC = Attributes + Conditions (e.g., aws:PrincipalTag/clearance).
3. SSO = Okta/Azure AD + OIDC/SAML. ⚠️ Always test in the customer’s network.
4. MFA = Non-negotiable in regulated environments. Use Duo/Google Authenticator.
5. Service Accounts = Non-human identities (e.g., K8s ServiceAccount, AWS IAM roles).
6. LDAP/AD = ldapsearch -x -H ldap://dc.example.com -b "dc=example,dc=com".
7. OAuth/OIDC = curl https://idp.example.com/.well-known/openid-configuration.
8. SAML = XML-based SSO. Use saml-tracer to debug.
9. Zero Trust = “Never trust, always verify.” Assume breach.
10. Fallbacks = Always have a backup (e.g., local LDAP, static creds) for air-gapped environments.

⚠️ Field Traps:
- “It works in my lab” ≠ “It works in the customer’s environment.” - Hardcoded credentials will fail audits.
- MFA is not optional—push back if the customer resists.
- SSO breaks in air-gapped networks—plan for this.