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

Add IAM overview document for operators #119

Merged
merged 5 commits into from
Dec 12, 2023
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
75 changes: 75 additions & 0 deletions docs/05-iam/index.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,75 @@
# Introduction on Identity Management and Federation in SCS

Sovereign Cloud Stack wants to make it possible for operators to delegate
administration of user identities to the organizational entities that the
users are part of. Usually that's customer organizations but it could also
be the operator itself. Federation protocols like OpenID Connect can be used
to achieve that goal. To simplify connecting the different parts of SCS
to customer owned IAM solutions, the SCS reference implementation offers
Keycloak as central Identity Provider (IdP) service.

## Deployment

Keycloak can be deployed by running

```
osism apply keycloak
```

The required Keycloak client configuration that allows Keystone to obtain
OIDC token from Keycloak needs to be deployed by running

```
osism apply keycloak-oidc-client-config
```

After these steps Keystone should be able to obtain token using the
Device Authorization Grant with PKCE, which is configured by default in the
`wsgi-keystone.conf` deployed in SCS.

## Accessing Keycloak

Currently deployed on the manager node, by default under `https://keycloak.<yourdomain>`.
Details TODO.

## Identity Mapping

The idea is that customer can create groups with specific names in their own IAM.
These shall be mapped to a claim `groups` to be included in the OIDC token.
Via the Keystone [mapping](https://docs.openstack.org/keystone/latest/admin/federation/mapping_combinations.html)
they shall be mapped to roles on OpenStack projects.
[The corresponding section for Developers](https://docs.scs.community/dev-docs/operations/iam/identity-federation-in-scs) may be interesting for more technical details.
reqa marked this conversation as resolved.
Show resolved Hide resolved
Please be aware that currently there are still some technical challenges to be solved
within the OpenStack Keystone mapping engine and the mapping rules to make this work
seamlessly.

## SCS to SCS federation

Federation between separate deployments of SCS is possible via the IdP by
means of OpenID Connect.
The section on [inter SCS federation setup](https://docs.scs.community/docs/iam/intra-SCS-federation-setup-description-for-osism-doc-operations) explains the required steps in some detail.
reqa marked this conversation as resolved.
Show resolved Hide resolved

### Prerequisites and Requirements

- Knowledge: Familiarity with Keycloak, OIDC federation, and basic SSL and web security principles is pivotal.
- Software: The core software component is the OpenID-Connect identity provider, configured to function optimally with OpenStack environments. While the SCS reference implementation focusses on Keycloak as IdP, with appropriate configuration adjustments any OAuth 2.0 compliant IdP should be suitable as an alternative. Each implemntation may have its own pros and cons.

### Features

- Horizon Web SSO
- OpenStack CLI use via the Device Authorization Grant

### Limitations

- Keystone currently still has limitations in its mapping engine, which are addressed by the SCS development team as we
see possibilities and alignement with upstream OpenDev development plans. Automatically creating `ephemeral` users in
their specific OpenStack domains, as specified in their OIDC token is one example, currently beeing worked on. Please
check carefully if the technical results meet the security demands of your specific environment.

### Current state and future Outlook

Currently SCS exemplifies deploying Keycloak on the management plane. This shall be moved to a Kubernetes based
management plane to improve scalability and architecture.

In the near future, the Container layer shall be able to make use of the IdP to allow federated users to access Kubernetes.
In the mid term, workloads on Kubernetes shall be able to make use of OAuth tokens to access resources on the IaaS layer.
3 changes: 2 additions & 1 deletion sidebarsDocs.js
Original file line number Diff line number Diff line change
Expand Up @@ -363,7 +363,8 @@ const sidebarsDocs = {
type: 'category',
label: 'Identity and Access Management (IAM)',
link: {
type: 'generated-index'
type: 'doc',
id: 'iam/index'
},
items: [
'iam/intra-SCS-federation-setup-description-for-osism-doc-operations'
Expand Down
2 changes: 1 addition & 1 deletion src/pages/index.tsx
Original file line number Diff line number Diff line change
Expand Up @@ -142,7 +142,7 @@ export default function Home(): JSX.Element {
title="IAM Layer"
body="Working on Keycloak federated identity provider within our Team IAM."
buttonText="Learn More"
url="/docs/category/identity-and-access-management-iam"
url="/docs/iam"
/>
</div>
</div>
Expand Down